Patterning the Relationships | UML 2 For Dummies

If you build systems, you may experience déjà vu—the same kinds of subsystems appear in different system architectures. You’re not losing your mind. Many systems display similar architectural patterns when you structure their subsystems. You make use of these patterns to solve common design problems when you start putting your system together. An architectural pattern gives you a reusable template to base your systems design.

Utilizing the three-tier architecture pattern

Three-tier architecture is a common pattern for systems. This pattern separates your system into three distinct areas of behavior found in almost every system (presentation to the user, business logic, and object persistence). It also separates subsystems by technology (for example, user interface, application, database) and machine location (user-client machine, server machine, database machine). What you get (ideally) is a consistent user interface across multiple applications. But not all related behavior is confined to the same subsystem. For example, handling an instance of the Order class is done in several different places.

Using the three-tier architecture pattern you decompose your system into three subsystems:

Presentation: The subsystem that plays the Presentation role is responsible for all interactions with the user of the system.
Business Logic: This subsystem must perform calculations and make sure the application adheres to business rules. This is where the real work of the application takes place, independent of any user interfaces.
Database: The back end of the system is the subsystem that plays the role of the database. This subsystem is responsible for storing any data or objects that must persist beyond the runtime of the application.

Modeling architectural patterns

You use a collaboration to diagram an architectural pattern. If you’re showing just the pattern, draw a dashed oval with the name of the collaboration at the top. Draw a dashed line to separate the name of the collaboration from the elements depicted as involved in the pattern collaboration. In the main body of the oval show a simple diagram with the subsystems that interact to form the pattern. You name the subsystem in such a way as to indicate the role they play in the pattern. You can also show connections between the subsystems and any other dependencies between the subsystems that make up the pattern. (See Chapter 15 for more on collaborations.)

Figure 20-8 illustrates the three-tier pattern. The basic idea is quite simple, three subsystems labeled Presentation, Business Logic, and Database are contained inside a named collaboration oval. The dependencies between the three subsystems are also show to further clarify the pattern. If you use this pattern your three subsystem must follow the pattern of dependencies shown in the diagram.

Figure 20-8: Three-tier architectural pattern.

When you want to show a specific “occurrence” of a pattern, you draw a collaboration occurrence—a small, named collaboration oval—and don’t forget the dashes. To show each your specific subsystems that participate in the pattern, use a dashed line to connect each subsystem to the collaboration oval. Then, at the end of the dashed line next to each subsystem, show the role that subsystem plays in the pattern. Role names come from the generic pattern description.

Figure 20-9 shows an occurrence of the three-tier pattern for the air-filter business example. A subsystem called OrderViewClient plays the role of the Presentation subsystem. The OrderViewClient is responsible for presenting screen views of order and customer information to the user. The OrderHandlingServer subsystem performs all the business logic of the order-handling application. It, in turn, depends on the PersistentStore subsystem to play the role of the Database part of the pattern. PersistentStore is responsible for all storage and retrieval of order and customer information.

Figure 20-9: Collaboration occurrence of a three-tier architectural pattern.

Using other architectural patterns

It can be especially helpful to use architectural patterns to get you started with decomposing your system into subsystems. You may want to consider the following other architectural patterns:

Façade: You provide a simple interface, the façade, to hide complex internal details, such as the system’s subsystems, components, and/or classes. Many complex subsystems use this pattern to hide their complexity from other subsystems.
Adapter: You want to convert the interface of an existing system or subsystem, the adaptee, to an interface more easily used, the adaptor. This pattern serves to “wrap” legacy systems and hide the old interface to the legacy system.
Master-slave: You have to have one subsystem, the master, in complete control of other subsystems, the slaves. The master issues commands and accepts responses from the slaves. Command and control systems tend to use this pattern.
Pipe-filter: When you want a system that must perform a step-by-step sequence based purely on data input, you actually have two tasks:
- Create a pipeline architecture with subsystems that perform each step.
- Create a subsystem to hold the data.
  
  The subsystems that perform each step can also filter the data passing through them. Signal-processing systems and batch-oriented systems (for example) use this pattern.