After collecting requirements from customers, we have to define the architecture of the system
So, we need to find a high-level subdivision of the system into constituent parts
Need to orgainize the mess into a workable structure
We will introduce the Layers pattern to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction
Networking protocols is the best known
The International Standardization Organization (ISO) defined the following architectural model, the OSI 7-Layer Model
| Application | Layer 7 | Provides misc protocols for common activities (ftp, telnet, http, etc) |
| Presentation | Layer 6 | Structures information and attaches semantics |
| Session | Layer 5 | Provides dialog control and synchronization facilities |
| Transport | Layer 4 | Breaks messages into packets and guarantee delivery |
| Network | Layer 3 | Select a route from sender to receiver |
| Data Link | Layer 2 | Detects and corrects errors in bit sequences |
| Physical | Layer 1 | Transmits bits: velocity, bit-code, connection, etc |
Layered approach is considered better practice, since different issues separately reaps several benefits
For example, development by team, support incremental coding, testing
Rewriting can be down on a certain layer only
A large system that require decomposition
The system we are building is divided by mix of low and high level issues, where high-level operations reply on the lower-level ones
For example, high-level will be interactive to user and low-level will be concerned with hardware implementation
So, we need to balance the following requirements:
- Late source code changes should not ripple the whole system
- Interface should be stable (or better yet defined by standard)
- Parts of the system should be exchangeable (i.e., a particular layer can be changed)
- Might need to build other systems with the same low level issues
- Grouping of component is needed
- Complex components need further decomposition
- The system will be built by a team of programmers
Structure your system into an appropriate number of layers and place them on top of each other
The lowest layer is called Layer 1 ... Layer J-1, Layer J ... the highest is called Layer N
Most of the services that Layer J provides are composed of services provided by Layer J - 1.
Thus, the services of each layer implement a strategy for combining the services of the layer below in a meaningful way. (Whether you would like exception of not depends on the system you build)
Class
Responsibility
Collaborator
|
Services of Layer J only used by Layer J+1 - there are no further direct dependencies between layers
The following represents a high conceptual view of Layers:
Client ---------- uses ----------------- Layer N
Layer N-1
...
Layer 1
In more detail, it might look something like this:
| Layer 3 --- Component 3.1 --- Component 3.2 ---- Component 3.3 |
|| | ||
|| |--------------||
| Layer 2 --- Component 2.1 --- Component 2.2 <--> Component 2.3 |
|| | ||
|---------------| ||
| Layer 1 --- Component 1.1 --- Component 1.2 ---- Component 1.3 |
Scenario I (Client called to Layer N)
Client issues a request to Layer N
Layer N cannot carry out, so it calls to Layer N-1 for services
Layer N - 1 sends requests to Layer N - 2
... Layer 2 sends requests to Layer 1
Services finally get performed in Layer 1
Replies passed back up from Layer 1 to Layer 2 ...
Replies passed back up from Layer N -2 to Layer N - 1
Reply passed back up from Layer N - 1 to Layer N
(Single request might get mapped to mulitple requests when going to lower layers)
Scenario II (Bottom-up communication)
A chain of actions starts at Layer 1 (a device driver detects input ...)
Inputs are translated into an internal format for Layer 2
... go to Layer 3,4,5 and so on ...
A "response" are detected in Layer N
(Called notifications)
(Scenario I is fan out, Scenario II is either remain 1:1 or condensed into a single notification)
Scenario III (Requests only travel through a subset of the layers from top to bottom)
Request to Layer N
Layer N calls Layer N-1 for services then "stop"
(Layer like this have to maintain state information / control info)
(Caching is one example of this scenario)
Scenario IV (Requests only travel through a subset of the layers from bottom to top)
An event is detected in Layer 1
Replies to Layer 2, then Layer 3, then "stop"
(Layer 3 probably has checking in place to look for repeated request from lower layers)
Scenario V (Communicate with 2 stacks)
...
Define the abstraction criterion
Common Layers Principles
- User-visible elements
- Specific application modules
- Common services level
- Operating system interface level
- Operating system
- Hardware
Determine the number of abstraction levels
Name the layers and assign tasks to each of them
Specify the services
Refine the layering
Specify an interface for each layer
Structure individual layers
Specify the communication between adjacent layers
Decouple adjacent layer
(For example, upper layers know lower layers, but not vice versa)
(Higher layers register callback and still maintain upper layer hidden)
(Could relax some constraint for performance)
Design an error-handling strategy
Relaxed Layerd System
Layering Through Inheritance
Shared Component for some Layers
JVM
APIs
AS/400 MI
TCP/IP
Windows NT with Relaxed Layered system
ERP
Advantages
Reuse of Layers
Support for standardization - dependencies are kept local
Exchangeability
Disadvantages
Cascades of changing behavior when behavior of a layer changes ... e.g. lower layer output increase 100x
Lower efficiency
Unnecessary work
Difficulty of establishing the correct granularity of layers