Class diagram

I expect that even people who have never seen UML before will understand 80% of what the diagram is intended to communicate by looking at it for a minute or two. The diagram also contains some FOST.3™ conventions, so to understand everything in the diagram you'll still need some help.

All of the classes in the diagram are used for the persistence of the static data supplied by Netflix. Each class represents exactly one database table, for example, Object is a representation of the FSLib_Object table and Movie is a representation of the Netflix_Movie table (the diagram doesn't explicitly show the namespaces that lead to the name prefixes). That these are persistent classes is shown by the icon above the class name (which in turn represents the <<Table>> stereotype for those who already know UML).

As well as the database tables the FOST.3™ UML compiler will also create C++ classes which allow me to easily access the data from that language and it creates a COM layer (sitting on the C++ layer) which allows me to easily access the data from scripting languages, or any other programming environment that gives access to COM/ActiveX objects.

Under the class name are the attributes. The format for an attribute is:

• The stereotype is used to convey extra information about the applicability or implementation of the attribute. For example the <<PK>> stereotype on Partition's sortOrder attribute tells us that it is part of the table's primary key.
• The name is the name we will use to reference the attribute through COM or C++ and it will also be used to create the table column name. For example, the table Netflix_Movie will contain a column name (amongst others).
• The type is either an SQL column type, a FOST.3™ type or some other common type. The representation of these types changes depending on the language they're being accessed through. For example TrainingScore.when is a char (23) in the database, a TimeStamp class in C++ and a string through COM. Nullable<> is a wrapper type that shows the attribute can take null values.

Lines with simple arrows at the end (such as the one between TrainingScore and Customer) also represents an attribute. The name is written next to it (customer) and it may also have multiplicity (1 in this case). There may also be a stereotype (here showing it will be part of the primary key for TrainingScore).

Facets

The final type of relationship that is in the diagram involves some FOST.3™ specific terminology, but the concepts they express are normal object oriented ones.

Each customer that we wish to store has made many ratings over all sorts of films. In a database we can't store these as a single column, we instead use a seperate table joined to the customer table. The FOST.3™ concept of facets embodies this notion. When we look at the line between Customer and Rating the notation tells us that Rating is a facet of Customer, which we call the owner (shown by the <<owner>> stereotype on the link). The diamond on the Rating end of the line shows an aggregation. This means that if a Customer instance is deleted then all of the Rating instances it owns are deleted at the same time.

The link also has a name at each end. The Rating has a normal attribute (that is an SQL column, C++ attribute and COM property) called customer, but the attribute that Customer has is different.

In the database there is no column. To find the ratings given by a given customer a suitable SQL JOIN can be used. At the COM level the Customer has a property ratings which is a collection (and implements the IEnumVARIANT interface amongst others) through which all the ratings can be accessed. In C++ there is also attribute ratings which can be used to access the customer's ratings.

A minor error

Of course no design is really complete until you've built and delivered the system. Whilst thinking about how the audit phase of the process needs to work I realised that I was missing a small bit of information for the probe and qualifying data. In order to have the full information available from those data sets the Request class needs to store the date that the customer rated the film. To deal with this the class includes an extra attribute:

when : TimeStamp

• 840 × 782