Collaborations with the Layers Pattern - UML

Two design decisions at an architectural level are:

  1. What are the big parts?
  2. How are they connected?

Whereas the architectural Layers pattern guides defining the big parts,
microarchitectural design patterns such as Facade, Controller, and Observer are commonly used for the design of the connections between layers and packages. This section examines patterns in connection and communication between layers and packages.

Simple Packages versus Subsystems

Some packages or layers are not just conceptual groups of things, but are true subsystems with behavior and interfaces. To contrast:

  1. The Pricing package is not a subsystem; it simply groups the factory and strategies used in pricing. Likewise with Foundation packages such as java.util.
  2. On the other hand, the Persistence, POSRuleEngine, and Jess packages are subsystems. They are discrete engines with cohesive responsibilities that do work.

In the UML, a subsystem can be identified with a stereotype, as in Figure.


For packages that represent subsystems, the most common pattern of access is Facade, a GoF design pattern. That is, a public facade object defines the services for the subsystem, and clients collaborate with the facade, not internal subsystem components. This is true of the POSRuleEngineFacade and the PersistenceFacade for access to the rules engine and persistence subsystem.

The facade should not normally expose many low - level operations. Rather, it is desirable for the facade to expose a small number of high - level operations the coarse - grained services. When a facade does expose many low - level operations, it tends to become incohesive. Furthermore, if the facade will be, or might become, a distributed or remote object (such as an EJB session bean, or RMI server object), fine - grained services lead to remote communication performance problems lots of little remote calls are a performance bottleneck in distributed systems.

Figure 34.5 Subsystem stereotypes

Also, a facade does not normally do its own work. Rather, it is consolidator or mediator to the underlying subsystem objects, which do the work.

For example, the POSRuleEngineFacade is the wrapper and single point of access into the rules engine for the POS application. Other packages do not see the implementation of this subsystem, as it is hidden behind the facade. Suppose (this is just one of many implementations) that the POS rules engine subsystem is implemented by collaborating with the Jess rules engine. Jess is a subsystem that exposes many fine - grained operations (this is common for very general, third - party subsystems). But the POSRuleEngineFacade does not expose the low - level Jess operations in its interface. Rather, it provides only a few high - level operation such as is invaliddineltem, sale).

If the application has only a "small" number of system operations, then it is common for the Application or Domain layer to expose only one object to an upper layer. On the other hand, the Technical Services layer, which contains several subsystems, exposes at least one facade (or several public objects, if facades aren't used) for each subsystem to upper layers. See Figure.

Session Facades and the Application Layer

In contrast to Figure, when an application has many system operations and supports many use cases, it is common to have more than one object mediating between the UI and Domain layers. for applications with only a few system operations, perhaps only one object acts as the facade into the layer

Figure 34.6 Number of interfaces exposed to upper layers

However, as the system grows to handle many use cases and system operations, it is not uncommon to introduce an Application layer of objects that maintain session state for the operations of a use case, where each session instance represents a session with one client. These are called Session Facades, and their use is another recommendation of the GRASP Controller pattern, such as in the use - case session facade controller variant of the pattern. See Figure for an example of how the NextGen architecture may evolve with an Application layer and session facades.

Figure 34.7 Session facades and an Application Layer

Figure 34.8 The Controller choices


The GRASP Controller pattern describes common choices in client - side handlers (or controllers, as they've been called) for system operation requests emitting from the UI layer. Figure illustrates.

System Operations and Layers

The SSDs illustrate the system operations, hiding UI objects from the diagram. The system operations being invoked on the system in Figure are requests being generated by an actor via the UI layer, onto the Application or Domain layer.

Figure 34.9 System operations in the SSDs and in terms of layers

Upward Collaboration with Observer

The Facade pattern is commonly used for "downward" collaboration from a higher to a lower layer, or for access to services in another subsystem of the same layer. When the lower Application or Domain layer needs to communicate upward with the UI layer, it is usually via the Observer pattern. That is, UI objects in the higher UI layer implement an interface such as Property / Listener or AlarmListener, and are subscribers or listeners to events (such as property or alarm events) coming from objects in the lower layers. The lower layer objects are directly sending messages to the upper layer UI objects, but the coupling is only to the objects viewed as things that implement an interface, such as PropertyListener,not viewed as specific GUI windows.

This was examined when the Observer pattern was introduced. Figure summarizes the idea in relation to layers.

Figure 34.10 Observer for "upward" communication to the Ul layer

Relaxed Layered Coupling

The layers in most layered architectures are not coupled in the same limited sense as a network protocol based on the OSI 7 - Layer Model. In the protocol model, there is strict restriction that elements of layer N only access the services of the immediate lower layer N - l.

This is rarely followed in information system architectures. Rather, the standard is a "relaxed layered" or "transparent layered" architecture [BMRSS96], in which elements of a layer collaborate with or are coupled to several other layers.

Comments on typical coupling between layers:

  1. All higher layers have dependencies on the Technical Services and Foundations layer.
      For example, in Java all layers depend on java.util package elements.
  2. It is primarily the Domain layer that has dependency on the Business Infrastructure layer.
  3. The UI layer makes calls on the Application layer, which makes service calls on the Domain layer; the UI layer does not call on the Domain, unless there is no Application layer.
  4. If it is a single - process "desktop" application, software objects in the Domain layer are directly visible to, or passed between, UI, Application, and to a lesser extent, Technical Services.
    • For example, assuming the NextGen POS system is of this type, a Sale and a Payment object could be directly visible to the GUI UI Layer, and also passed into the Persistence subsystem in the Technical Services layer.
  5. On the other hand, if it is a distributed system, then serializable replicates (also known as data holder or value objects) of objects in the Domain layer are usually passed to a UI layer. In this case, the Domain layer is deployed on a server computer, and client nodes get copies of server data.

Isn't Coupling to Technical and Foundation Layers Dangerous?

As the GRASP Protected Variations and Low Coupling discussions explored, it is not coupling per se that is a problem, but unnecessary coupling to variation and evolution points that are unstable and expensive to fix. There is very little justification in spending time and money attempting to abstract or hide something that is unlikely to change, or if it did, the change impact cost would be negligible. For example, if building a Java technologies application, what value is there in hiding the application from access to the Java libraries? High coupling into many points of the libraries is an unlikely problem, as they are (relatively) stable and ubiquitous.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

UML Topics