34.1. Example: NextGen Logical Architecture
example of common layers p. 202 Figure 34.1 illustrates a partial logical layered architecture for this iteration of NextGen application.
Figure 34.1. Partial logical view of layers in the NextGen application.
[View full size image]
- There are other types in these packages; only a few are shown to indicate noteworthy aspects.
- 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 String manipulation utilities.
- 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 34.2.
Figure 34.2. Partial coupling between packages.
[View full size image]
- 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 Sales package 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 34.3.
Figure 34.3. Partial package coupling.
Inter-Layer and Inter-Package Interaction Scenarios
Package diagrams show static information. To help someone understand the dynamics in 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 34.4 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.
[View full size image]
- The package of a type can optionally be shown by qualifying the type with the UML path name expression <PackageName>::<TypeName> . 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.
- 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, oras shown hereas 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).
- 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.