Login | Register   
LinkedIn
Google+
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 2: Mastering Associations : Page 3

Associations are a key part of the UML lexicon. Use them to define the ways in which your application's classes communicate. In this article you'll see that adding a database introduces design patterns for the first time using the façade pattern.


advertisement
The Refactored Implementation
So far, I've refactored the implementation without coding. To prove that this really is a better way of doing things, I'll look at the refactored implementation of the classes.

using System; using System.Collections; public class Broker: implements IBrokerageCollection; { dbFacade db = new dbFacade(); void addBroker(String Name) { dbFacade.addMember(Name, “Broker”); }; void deleteBroker(String Name); { dbFacade.deleteMember(Name, “Broker”); } ArrayList listBrokers(); { Return (ArrayList) dbFacade.listBrokers(“Broker”); } public class Client (); // Add all of the same database logic as in Broker public class Security(); // Add all of the same database logic as in Broker } }

If I were feeling ambitious there is some more refactoring that I could do. I could pass in "Broker" to the constructor and return a reference that would always use the broker table. The important accomplishment is the encapsulation of the intricate C# ADO code to a single class. With that done, the class can be assigned to a database specialist to code out the ADO, call SQL stored procedures, and find the most efficient method for implementing the database. Should that database change, only the database specialist is affected, leaving typical developers like you free to focus on the business logic.

Some Final Thoughts
In the process of adding an association you've learned:
  • what an association is and how it is implemented in code.
  • some more about interfaces and that interfaces can act as templates or patterns, such as the façade pattern which encapsulates implementation details.
  • about style and that diagrams do not always look the same even though the UML rules are still followed.
  • about refactoring and the time and effort that can be saved by accomplishing it before any code is written.
  • that by designing systems using some of the ideas discussed here the separation of concerns can be enforced.
Next
The next step in the UML process is to learn about whole-part relationships. In UML, the whole-part relationship is represented by special associations called aggregation and composition. UML modelers will use either one or the other because of their similarity in code, however you will learn that there are differences and these differences can be critical to developing a system. It will be an exciting time as you begin to effect collaboration between the classes you've created in, using other classes and just plain having fun.



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.

 

 

Sitemap