Two design decisions at an architectural level are:
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:
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:
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.
UML Related Interview Questions
|Adv Java Interview Questions||Java collections framework Interview Questions|
|Design Patterns Interview Questions||Rational robot Interview Questions|
|Web semantic Interview Questions||Spring MVC Framework Interview Questions|
|Advanced C++ Interview Questions||Advanced jQuery Interview Questions|
|XML DOM Interview Questions||Object Oriented Analysis and Design Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.