Example: NextGen Logical Architecture - UML

Figure illustrates a partial logical layered architecture for this iteration of NextGen application.

Figure 34.1 Partial logical view of layers in the NextGen application

Note the absence of an Application layer for this iteration of the design; as discussed later, it is not always necessary.

Since this is iterative development, it is normal to create a design of layers that starts simple, and evolves over the iterations of the elaboration phase. One goal of this phase is to have the core architecture established (designed and implemented) by the end of the iterations in elaboration, but this does not mean doing a large up - front speculative architectural design before starting to program. Rather, a tentative logical architecture is designed in the early iterations, and it evolves incrementally through the elaboration phase.

Observe that just a few sample types are present in this package diagram; this is not only motivated by limited page space in formatting this book, but is a signature quality of an architectural view diagram - it only shows a few noteworthy elements in order to concisely convey the big ideas of the architecturally significant aspects. The idea in a UP architectural view document is to say to the reader, "I've chosen this small set of instructive elements to convey the big ideas."

Comments on Figure:

1. There are other types in these packages; only a few are shown to indicate noteworthy aspects.


2. The Foundation layer was not shown in this view; the architect (me) decided it did not add interesting information, even though the development team will certainly be adding some Foundation classes, such as more advanced Stringmanipulation utilities.


3. For now, a separate Application layer is not used. The responsibilities of control or session objects in the Application layer are handled by the Register object. The architect will add an Application layer in a later iteration as the behavior grows in complexity, and alternative client interfaces are introduced (such as a Web browser and wireless networked handheld PDA).

Inter - Layer and Inter - Package Coupling

To help someone understand the NextGen logical architecture, it's also informative to include a diagram in the logical view that illustrates noteworthy coupling between the layers and packages. A partial example is illustrated in Figure.

Figure 34.2 Partial coupling between packages

Applying UML:

Observe that dependency lines can be used to communicate coupling between packages or types in packages. Plain dependency lines are excellent when the communicator does not care to be more specific on the exact dependency (attribute visibility, subclassing, ...), but just wants to highlight general dependencies.

Note also the use of a dependency line emitting from a package rather than a particular type, such as from the Salespackage to POSRuleEngineFacade class, and the Domain package to the Log4J package. This is useful when either the specific dependent type is not interesting, or the communicator wants to suggest that many elements of the package may share that dependency.

Another common use of a package diagram is to hide the specific types, and focus on illustrating the package - package coupling, as in the partial diagram of Figure.

Figure 34.3 Partial package coupling

In fact, Figure illustrates probably the most common style of logical architecture diagram in the UML - a package diagram that shows between perhaps 5 to 20 major packages, and their dependencies.

Inter - Layer and Inter - Package Interaction Scenarios

Package diagrams show static information. To help someone understand the dynamicsin the NextGen logical architecture, it's also useful to include a diagram of how objects across the layers connect and communicate. Thus, an interaction diagram is helpful. In the spirit of an "architectural view" which hides uninteresting details, and emphasizes what the architect wants to convey, an interaction diagram in the logical view of the architecture focuses on the collaborations as they cross layer and package boundaries. A set of interaction diagrams that illustrate architecturally significant scenarios (in the sense that they illustrate many aspects of the large - scale or big ideas in the design) is thus useful.

For example, Figure illustrates part of a Process Sale scenario that emphasizes the connection points across the layers and packages.

Figure 34.4 An architecturally significant interaction diagram that emphasizes cross - boundary connections

Applying UML:

1. The package of a type can optionally be shown by qualifying the type with the UML path nameexpression <PackageName>::<TypeName>


2. For example, Domain :: Sales :: Register. This can be exploited to highlight to the reader the inter - package and inter - layer connections in the interaction diagram.


3. Note also the use of the subsystem stereotype. In the UML, a subsystem is a discrete entity that has behavior and interfaces. A subsystem can be modeled as a special kind of package, or as shown here as an object, which is useful when one wants to show inter - subsystem (or system) collaborations. In the UML, the entire system is also a "subsystem" (the root one), and thus can also be shown as an object in interaction diagrams (such as an SSD).


4. Note the use of the '1 in the top right corner to indicate a singleton, and suggest access using the GoF Singleton pattern.

Observe that the diagram ignores showing some messages, such as certain Sale collaborations, in order to highlight architecturally significant interactions.