Browse DevX
Sign up for e-mail newsletters from DevX


UML for the Software Developer, Part 3: Aggregating : Page 3

Part 3 of this series on UML tackles aggregation, which is a special form of association. Part 2 showed you how associations related one class to another, but this article shows that associations are not strong enough when you need to specify ownership.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

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 modeler—either 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.

Final Thoughts
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 cases—in 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 classes—hope 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.

Mark Goetsch is an Enterprise Software Architect with Wheels, Inc, and has more than fifteen years of experience in software development, enterprise modeling, and software architecture. He has another seven years experience as a trader, dealer, Broker, and an expert in e-trading. He was one of the enterprise modelers of the Tapestry Project at ABNAMRO, one of the most extensive uses of UML component and deployment diagrams to date. He is the lead architect for the MAP (Meta-Architectural Processes) framework, which is a framework for mapping the role of the software architect into software development processes. Mark is certified in Intermediate UML with the OMG and a member of WWISA. He also has a Masters in Distributed Systems from DePaul University.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date