In Part 1 of this series, I reviewed a strategy for re-architecting an existing object-oriented design for an online storefront to take a Web services approach. This tip explores the first two steps of that process: simplifying persistence and system classes and simplifying hierarchies. These steps focus on conceptually simplifying the problem that you are tackling.
A common architectural strategy is to layer your application into different class types. I typically take a five-layer approach to building applications:
- User interface (UI) classes encapsulate the elements, such as HTML pages, GUI screens, and printed/electronic reports, that make up the user interface for your system.
-
Business/domain classes, also known as entity classes, implement the fundamental domain types within your application, such as the
OrderandCustomerclasses in Figure 1. - Process classes implement complex business logic, such as that offered by a potential Web service, that pertains to several classes.
- Persistence classes encapsulate access to your persistent stores, including relational databases, flat files, and object bases.
- System classes encapsulate technical features, such as your approach to interprocess communication (IPC) or error logging.
This approach is covered in more detail in my book, The Object Primer 2nd Edition: The Application Developer's Guide to Object Orientation (see Resources).
Figure 1 and all other examples in this series are drawn from the SWA Online example; see Part 1 for details.
Figure 1. Initial class model for SWA Online

Step 1: Simplify persistence and system classes
For this purpose, to identify business-oriented Web services, you're going to choose to ignore the persistence and system layers for now. Your persistence layer may be implemented in one of several ways, including but not limited to hardcoded SQL, data access classes such as Java Data Objects (JDOs), a service such as EJB's container-managed persistence (CMP), or one or more Web services. Similarly, your system layer may be implemented as an API, a collection of wrapper classes, or as Web services. These objects exist and they're important, but for the sake of simplicity you're going to take their existence for granted so you can focus on the business side of things. Figure 1 does not include any persistence or system classes, but if it did, you would want to create a view of our model that did not show them.
For the sake of identifying servers, inheritance and aggregation hierarchies can often be simplified. For inheritance hierarchies, a rule of thumb to follow is that if a subclass doesn't add a new contract, then it can effectively be ignored, and in general you can often consider a class hierarchy as a single class. In the Address classes outlined in Figure 2, the Territory class hierarchy could be simplified by ignoring State because it adds no new contracts. Furthermore, I'd be tempted to simply consider the entire hierarchy as one entity for now, since the remaining class, Country, only adds one contract, and frankly it's not all that exciting.
Figure 2. The Address classes

For aggregation hierarchies, you can ignore any "part classes" that are not associated to other classes outside of the aggregation hierarchy. In Figure 1, you can see that OrderContact can be ignored because Order is the only class to which it is associated. By collapsing aggregation and inheritance hierarchies, you simplify your model, making it easier to analyze when you define subsystems.
The result of your simplification efforts is Figure 3, which, as you can see, is a smaller model to work with than the original model in Figure 1.
Figure 3. Simplified class model for SWA Online

Once your model(s) have been simplified, the next steps are to analyze your design and begin to reorganize it into packages. This is the topic of the next tip in this series. Until then, you should consider how to apply the techniques outlined here to your own object-oriented applications.
- Read the first tip in this series, Deriving Web services from UML models, Part 1.
-
The Object Primer 2nd Edition: The Application Developer's Guide to Object Orientation, Scott W. Ambler (Cambridge University Press, 2001)
-
Agile Modeling: Best Practices for the Unified Process and Extreme Programming, Scott W. Ambler (John Wiley & Sons, 2002)
-
Design Patterns: Elements of Reusable Object-Oriented Software, E. Gamma, R. Helm, R. Johnson, and J. Vlissides (Addison-Wesley, 1995)
-
Component Software: Beyond Object-Oriented Programming, C. Szyperski (ACM Press, 1998)
- The Object Management Group's Website provides the latest specification for UML.
- Learn more about using VisualAge UML Designer.
- Once you've implemented your applications as Web services, you can list them in IBM's UDDI
version 2 registry.
Scott W. Ambler is a Practice Leader for Agile Development within the IBM Methods group. He develops process materials, speaks at conferences, and works with IBM clients worldwide to help improve their software processes. Scott is author of several books, listed on his Web site at www.ambysoft.com. Scott is also a recognized Ratonal Thought Leader, whose homepage may be viewed here.




