UML for the Software Developer, Part 2: Mastering Associations : Page 3

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.

Previous Page