A link to the full size image is at the bottom of the page
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:
<<stereotype>> name : type
sortOrderattribute tells us that it is part of the table's primary key.
Netflix_Moviewill contain a column
char (23)in the database, a
TimeStampclass 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
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
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
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.
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