Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

UML for the Software Developer, Part 3: Aggregating

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.


advertisement
n Part 2 we looked at associations, which are nothing more than references, but they can be directional and represent multiplicity. If we were restricted to our ability to generate code using UML this would be sufficient. If we are offering guidance on how the application should be built, as well as auto-generated code, we need something more. To continue with examples from the previous articles, your friends at Rich Men, Inc want to start tracking what stocks they buy for their clients. Ideally they would somehow offer some aggregated values for all of the stocks that a client has in order to boost their value to the client.

Iteration 1: Starting with a Few Associations
One rule that I follow when designing an application is to always start with the associations and the base classes. In order to avoid making any implicit assumptions, inheritance, the use of aggregation and composition, and even the multiplicity relationships are all saved for a later iteration. For the purposes of this article you aren't concerned with the storage and retrieval of these values, as you were in the last article. The client owns the securities so it is one directional and you can make the assumption that a client owns more than one security. Other attributes include the number of shares of the security and its current combined dollar value. I also added an operation called AddTrade that will allow us to add to both the quantity and the value of the security.

Figure 1. Associating the Client and Security Classes: Notice that Client and Security are individual classes, not members of a collection.
Seems complete! You have a client who owns some securities, can get the values of the securities and even add to them (for now let's assume that AddTrade can represent both the buying and selling of shares of a security). The only thing missing from this story is the value of all the securities. This should be simple as well. Add a TotalValue attribute and an operation CalculateValues that would run through all the securities and add their values up and the story should be complete. But there is a problem with this approach. You refer to this as SRP or the "Single-Responsibility Principle." A class should have one, and only one, purpose. This is what prevents the "god-class" anti-pattern. If your client class uses the class to hold the total values of the securities it would violate SRP to use the class to track the client's relationship as well.




Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap