Iteration 4: The Last Iteration
In the final iteration you added a Customers class to hold all the clients. You also added the Trades class for all the trades done for a particular client. When these class diagrams get large it is common to not add all of the attributes and operations. ClientCollection, StockCollection and TradeCollection are usually assumed and sometimes represented by multiplicity indicators on the class relationships. The AddTrade
method could be left out as well, since the Trades class would require that method in Security as well as other CRUD (create,
read, update, and delete) methods. Another practice seen in many diagrams is the UML modelereither using all composition relationships or all regular aggregation relationships.
|Figure 4. Adding the Trades and Customers Classes to the Final Iteration: The ClientCollection, StockCollection and TradeCollection attributes are not always explicitly represented. |
There are some other assumptions that could be made. The Quotes class requires a subscription method. One could change the Quotes class into an interface and use this as a generic method for plugging into any quote provider. The client may want to see the quote for a current stock to see if he wants to make a trade. Do you use the Portfolio class for this or do you instead have the Client class register directly with the Quotes class?
A final note: I put a getValuexQuantity
method in Trades. This method multiplies the price paid for the stock by its quantity (yet another assumption that the trade was made at one price). In this case, the equation for the stock value might be calculated in the following way:
Security.Value = 0;
Security.Quantity = 0;
For each trade in TradeCollection
Security.Quantity = trade.Quantity;
if (Security.Quantity <> 0)
Security.Value = trade.getValuexQuantity() / Security.Quantity;
That will give an average weighted value for all the trades for that stock. If you didn't need to maintain the trades at all, then you could even eliminate the Trades class and use the above calculation as a static average weighted value.
To recap: associations can represent ownership using aggregation if ownership is shared and composition it there is only one owner. If you auto-generate the code, you can not tell the difference, but in a large system there is often a difference between aggregation and composition (whether something is a utility class or attached to a specific class, for example).
|Author's Note: In many books, composition and aggregation are determined by the lifetimes of the objects not just the ownership. Ontology, however, deals with the semantics as related to classifications, not specific casesin other words, classes and not objects. It is more correct to think in terms of ownership, which is more consistent with how whole-part relationships are represented in ontology. The UML Reference by the Three Amigo's discusses some of this in detail.
This completes your foray into classeshope the trip was eventful. The examples were simple but contain the elements that you will find in every class diagram. In the next article, I leave the world of static diagrams and move on to diagrams for deploying the results of these diagrams on a system.