RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


UML for the Software Developer, Part 1: Building Classes : Page 4

Whatever language you code in, however you feel about documentation, and whichever process you ascribe to—you will need to model. Whether those models are in a formal charter, reference document, part of a diagram, or on the back of a napkin, you as a software developer will end up using models or modeling yourself.

Iteration 3: Namespaces and Refactoring
Figure 3. Refactored Classes: The brokerage class is broken down into three classes Broker, Client and Security.
If you look closely, there are already a couple of issues to think about. You have developed in anti-pattern parlance the "god" class—one that does everything. As experienced developers, this should immediately set off some mental triggers.

If this were all in code you would be refactoring the code by now, making changes to separate out the different concerns into their classes—in some cases writing new tests, putting in a new test harness and figuring out how to combine these classes together to hook back up to the GUI. This is quite a bit of work.

In this simple case, you would immediately recognize that there are some separate concerns here and develop them from the beginning as separate classes. However the temptation would be to hook every class into the GUI directly. If you were really good, you might see this problem immediately and build some type of class that would combine the three classes together, but that requires some forethought. UML provides us with an easier way to do this without the work.

In Figure 3 the brokerage class is broken down into three classes: Broker, Client and Security. You encapsulate the classes in the package Brokerage. In .NET you represent packages as namespaces. A namespace is a nice construct for separating the different concepts of an application or system. One can think of a namespace as a logical component.
namespace Brokerage
     public class Broker   
     public class Client  
     public class Security   
Figure 4. Class Using an Interface: An <<interface>> stereotype is the way to identify different types of classes using UML.
If you look closely you notice that all three classes have the same operations, and more importantly, they all operate on collections. This should trip yet another alarm—you can refactor this class to reduce the duplicated logic.

From a UML standpoint this will be easier when you start adding more methods to the classes. In UML you accomplish this using the <<interface>> stereotype. A stereotype is the way to identify different types of classes using UML. They can be user defined like <<my type>> or specific to UML like <<interface>>.

The <<interface>> stereotype in BrokerageCollection accomplishes two things. Every class that uses this interface will have the exact same functionality for using collections. It also simplifies the diagram. You may wonder why the classes inherit from an interface and not another class. Inheriting from a class would have allowed me to add Brokers, Clients, and Securities to BrokerageCollection (interfaces don't have attributes like classes do) but .NET languages (except for C++) do not allow for multiple inheritance from classes, so the interface was used instead. If you wanted Broker to later inherit from a Person, for example, this would be impossible if BrokerageCollection were not an interface.
using System;
using System.Collections;

public interface IBrokerageCollection
   void addMember (String name);  
   void deleteMember (String name);  
   ArrayList listMembers();
Two notes about the interface method. First, the public interface in code is IBrokerageCollection and BrokerageCollection in the model. My preference is to not use the "I" in front of the interface for modeling but if code generation is part of your modeling effort then it is a good idea to add the "I".

Second, in the example it could be argued that the System.Collections.ArrayList library class already has a method for adding, deleting, and listing members. There might, however, be other validation that is happening within the classes themselves. Specify that only strings can be added or deleted, for example. Validate on the number of characters or maybe restrict the brokers to specific identifiers rather than the names. You could also inherit three different types from System.Collections.ArrayList; BrokerCollection, ClientCollection, and SecurityCollection. In modeling, as in coding, there is often more than one solution.

I have covered how a UML class relates to code, but not yet how they relate to each other. You can easily see that it's cheaper—from a time perspective—to make changes in the class rather than in the code. In the next article I will cover how the classes interact. You will see how to use UML models to have the brokers sell the securities for their clients. Exciting stuff!

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.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date