3 Flashcards
Compare the Layer pattern to the Multi-tier pattern.
The Layer pattern is a module pattern, while the multi-tier pattern is an allocation pattern.
The layer pattern defines layers, which are groupings of modules that offer a cohesive set of services. It has a unidirectional allowed-to-use relation among the layers, which expose themselves through a public interface. This pattern is used to segment software in such a way that modules can be developed and evolved separately with little interaction among the parts. The grouped modules are structures of static components like source code packages, etc.
The multi-tier pattern defines tiers, which are logical groupings of software components. Connections exist within the same tier and between adjacent tiers (in one or both directions). This pattern is used to split a system into a number of computationally independent execution structures (groups of software and hardware) that are connected by some communications management. The grouped software components can be seen as dynamic runtime components that should be deployed together.
Illustrate one Module pattern and one Component-and-Connector pattern using an example view on the architecture of the same system.
Component-and-Connector pattern: client-server pattern
[Pic]
The client-server pattern is used to segregate common resources and services from a large number of distributed clients to one or a few locations to promote modifiability and reuse as well as scalability and availability by centralizing control over these resources and services.
Client counters send synchronous requests to the account server to retrieve account information from a shared repository of customer accounts. These requests are also automatically redirected to the backup server in case of failure. The server in turn has database access through a connector that allows reading, writing and monitoring of the database. After retrieving the necessary information, it will send it back to the client as a reply.
This diagram shows which components play a dynamic role at runtime.
Module Pattern: Layer pattern
[Pic]
The Layer pattern attempts to segment software into layers that can be developed separately and evolve with little interaction between them. Each layer is a grouping of modules that can provide a coherent set of services, and a unidirectional allowed-to-use relationship exists between the layers.
The Client UI provides the user interface used by counters. This calls a server layer dispatcher that handles communication with the server and provides fallback if necessary. The server can handle domain classes for accounts that in turn depend on a persistence layer for communication with MySQL or Oracle Databases.
Between the Client UI and Account layers, layer bridging happens so that the counter application knows which fields it can represent. This could possibly be better avoided by separate “data transfer objects” that sit somewhat to the side of the layers and serve to hold data together for transport between layers.
How does dependency inversion overcome the problems associated with the traditional procedural interpretation of usage in implementations of the Layer pattern?
In the traditional procedural interpretation, the dependency direction is downward from the high-level layers at the top to the low-level layers at the bottom. This means that high-level layers such as for the business logic are dependent on low-level utility layers for persistence, etc. This while the business logic obviously creates tremendous value and is really the core of your application, while the low-level layers are often more generic, cheaper and more easily interchangeable. Because of this direction of dependency, changes to the lower-level layers will lead to changes in the higher-level layers, requiring integration testing to be performed again.
[Pic]
Dependency inversion means that the high-level layer declares an interface that will then be implemented by a low-level layer. So the dependency direction is now from the outer low-level layer such as for persistence to the inner high-level layer such as for business logic. For example, if the persistence infrastructure changes from MySQL to PostgreSQL, only a new adapter needs to be created in the outer layer with a different implementation of the interface provided by the inner layer.
Consequently, changes to the outer layer do not affect the inner layer. The inner layers can also be compiled, executed and tested independently of the outer layers (e.g. by exchanging the outer layer with a mock for testing).
Sketch a skeleton implementation of the Cake pattern in Scala.
The cake pattern
Which modularization problems does the Aspect-Oriented pattern intend to solve and how?
There are crosscutting concerns such as logging, exception handling, etc. that can lead to code scattering
and tangling.
- Scattering means that the implementation for that concern across everything scattered
- Tangling means that the implementation is interwoven between the implementation of other concerns
Both phenomena can lead to problems related to code understanding and maintainability.
The Aspect-Oriented pattern attempts to separate crosscutting concerns into a separate module and
avoid the above-mentioned phenomons by the programming construct “aspect.” Such an aspect
consists of an advice and a pointcut expression.
- An advice contains the actual code for the cross-cutting concern
- A pointcut expression specifies the join points in the base code where the cross-cutting concern
code should be combined with the base code. These join points are specific to each
AOP language based on their join point model (e.g. in method invocation, error throwing,…)
Illustrate the “fragile base class” problem using an example code snippet,
Page 29.
Discuss the strengths and weaknesses of the Shared-Data pattern
Strengths
1. Reliable data persistence
(when using good DBMS such as Oracle, etc. and a capable administrator)
2. Concurrent access to persisted data is controlled through transaction management
(Controls what should happen when 2 applications try to modify the same cell in a DB,…)
3. Supports access control (who can write, read,…)
4. Controls data distribution (e.g., across multiple servers) and data caching.
Weaknesses
1. The shared-data store can be a performance bottleneck
2. The shared-data store can be a single point of failure
3. Produces and consumers of data can still be tightly coupled by their knowledge of the
structure of the shared data. They do not communicate directly with each other, but if one
component requires a small change to the DB schema then other components will still
need to be updated as well.
Sketch an activity diagram for a remote procedure call through a client-side proxy from the Broker pattern.
Page 31.
What architectural problems does the Model-View-Controller pattern solve.
User interface software is typically the most customized part of an interactive application. Users want to look at data from different perspectives, such as different charts or styles. Each must represent the current state of the data.
This requires keeping the user interface functionality separate from the application functionality while still being responsive to user input or changes in theunderlying application data. Multiple views must be able to be created, maintained and coordinated as the data changes.
The MVC pattern splits application functionality into 3 components: model, view, controller.
What are the responsibilities of the various component roles that are involved in the MVC?
Page 32.
What is the difference between black-box and white-box frameworks?
With a white-box framework, the implementation of the framework must be understood in order to use
it. Application-specific behavior is added by adding methods to subclasses of the classes of the
framework. Each method added to a subclass must conform to the internal conventions of the
superclasses, so their implementation must be understood.
With a black-box framework, only the external interface of components must be understood to use the
framework because the interface between components is defined by protocol. Application-specific
behavior is added by providing the framework with a set of custom components. These components
must each understand a particular protocol defined by the framework. The components can be
provided by a component library with interfaces to be implemented or implemented. For example, the
framework will call from each component first start(), then execute() and finally finish() which means
those methods must be implemented.
Discuss how to choose between applying a Client-Server or a Peer-to-Peer pattern in an architecture.
Page 34.
Compare asynchronous messaging to remote procedure calling with respect to the fallacy of transparent distribution.
Page 35.
Illustrate Akka’s implementation of the actor model using an example code snippet.
Page 36.
Discuss how actors provide stronger encapsulation than objects.
Page 38.
