Designing Layered Systems EEE465 2001 Reference: BMRSS96 2'2 Layers

1
Designing Layered SystemsEEE465 2001Reference
BMRSS96 2.2 Layers

• Major Greg Phillips
• Royal Military College of Canada
• Electrical and Computer Engineering
• greg.phillips_at_rmc.ca
• 1-613-541-6000 ext. 6190

2
Context

• Were taking a tour of several architectural
  styles
• Event-based
• Layered
• Data Flow
• Data Store/Repository
• Today well discuss one possible process for
  designing a layered system.

3
Recall Generic Problem Description

• dominant characteristic is a mix of high and low
  level issues
• high level operations rely on lower level ones
• pattern of communication flows from high to low
  level, or from low to high
• may also be horizontal structure (independent
  operations at same level of abstraction)
• portability between platforms is desirable
• external boundaries are specified (e.g.,
  interfaces)
• mapping of high-level tasks onto platform is not
  straightforward

4
Recall Generic Solution Description

• structure the system as a series of layers
• start at the lowest levellayer 1
• work your way up the abstraction ladder, putting
  layer J on layer J-1 until you reach the top
• most services provided by layer J are composed of
  services from layer J-1
• each layer may be very simple, or may have
  complex internal structure
• note that implementation may proceed in any order

5
Design Process Overview

• 1. Define the abstraction criterion
• 2. Determine the number of abstraction levels
• 3. Name the layers, and assign tasks to each
• 4. Specify the services
• 5. Refine the layering (iterate steps 1-4)
• 6. Specify an interface for each layer
• 7. Structure individual layers
• 8. Specify the communication between adjacent
  layers
• 9. Decouple adjacent layers
• 10. Design an error handling strategy

6
1. Define the abstraction criterion

• May be
• conceptual distance from platform
• degree of customisation for specific domains
• degree of conceptual complexity
• May be a mix of criteria, such as
• distance from hardware at lower levels
• conceptual complexity at higher levels
• for example (top to bottom)
• user-visible elements
• specific application modules
• common services
• operating system interface
• operating system (itself likely layered)
• hardware

7
2. Determine no. of abstraction levels

• May be that each abstraction level corresponds to
  one layer
• May be that mapping from levels to layers is not
  obvious
• Think about trade-offs
• too many layers may impose unnecessary overhead
• too few layers can result in poor structure
• see also Forces to Balance from last lecture

8
3. Name layers, and assign tasks

• Task of the highest layer is the overall system
  task, as perceived by the client
• All other layers are helpers to higher layers
• Lower layers provide an infrastructure
• designing from bottom up requires experience and
  foresight to find the right abstractions for the
  lower layers, so that they will adequately
  support the higher layers

9
4. Specify the services

• Layers must be strictly separated that is, no
  component may be spread over several layers
• Argument, return and error types of functions
  offered by layer J should be
• built-in types
• types defined by layer J
• types taken from a shared data definition module
• note that this relaxes strict layering somewhat
• Generally locate more services in higher layers
  fewer in lower ones
• this prevents developers from having to learn a
  large number of similar primitives
• also reduces change during implementation

10
5. Refine the layering

• Usually not possible to define abstraction
  criterion without thinking of layers and services
• Usually wrong to define components and services
  first, then impose layered structure
• Natural solution is to iterate the first four
  steps

Like almost all other kinds of development,
finding layers does not proceed in an orderly,
logical way, but consists of both top-down and
bottom-up steps, and a certain amount of
inspiration Ralph Johnson
11
6. Specify an interface for each layer

• In general, layer J should be a black box for
  layer J1
• If necessary, encapsulate layer Js interfaces in
  a Façade object GHJV95
• Exceptions can be made for
• efficiency
• need to access internals of another layer
• but these are very seldom required or truly
  appropriate

12
7. Structure individual layers

• When an individual layer is complex, it should be
  broken into well-defined components
• A reasonable approach is to use good,
  object-oriented design principles, supplemented
  by appropriate design patterns. Two of these are
• Bridgeto support multiple implementations of
  services provided by a layer GHJV95
• Strategyto allow the dynamic exchange of
  algorithms used by a layer GHJV95

13
8. Specify communication between layers

• Most often used method is push
• required information passed by layer J1 to layer
  J in the service request/method call
• Alternative is pull
• lower layer requests information from upper once
  it has been invoked
• Pull introduces additional dependencies between
  layers, unless handled by callbacks

14
9. Decouple adjacent layers

• Normally, top down coupling
• upper layers know about, and call, lower layers
• ideal for top-down invocation sequences
• For bottom-up communication can use callbacks to
  preserve one-way coupling
• most effective when a limited event vocabulary is
  used in the callbacks
• Command pattern GHJV95 shows how to encapsulate
  callback functions into first-class objects
• Where lots of communication is bottom up, may
  need to have two-way coupling
• Can decouple further (down or up) by coding
  against interfaces rather than implementations

15
10. Design error handling strategy

• Error handling problematic in layered systems
• error handled in layer where it occurred, or
• forwarded to the next higher layer
• in this case, must be transformed into something
  meaningful
• Try to handle errors at lowest possible level
• If necessary to forward errors, try to condense
  into abstractions relevant to upper layers

16
Design Process Overview

• 1. Define the abstraction criterion
• 2. Determine the number of abstraction levels
• 3. Name the layers, and assign tasks to each
• 4. Specify the services
• 5. Refine the layering (iterate steps 1-4)
• 6. Specify an interface for each layer
• 7. Structure individual layers
• 8. Specify the communication between adjacent
  layers
• 9. Decouple adjacent layers
• 10. Design an error handling strategy

17
Next ClassLayered System Examples and Variants