Layers

1
Layers
2
Layering Mechanisms

• Introduction to layering design principles
• Determining when to use layers
• The attention points when layering
• Layering and PAC model

3
Layered Systems

• Hierarchically organised
• A layer provides services to layer(s) above it
• A layer is a client to layer(s) below it
• Possible topological constraints (opaqueness)
• Limit interactions between adjacent layers

4
Examples of layered Systems

• Layered communication protocols (e.g. OSI)
• OS kernels (e.g. Windows, Chorus)
• Database systems (e.g. ANSI/SPARC)
• Many commercial apps use layers model
• The agents in a PAC model!

5
Generic OS Environment

• User-visible elements (layer 6)
• Specific application modules (layer 5)
• Common services level (layer 4)
• OS interface level (layer 3)
• OS (may itself be layered) (layer 2)
• Hardware (layer 1)

6
Typical Layers Regime
7
Reasons for layered Systems

• Support designs based in increasing levels of
  abstraction
• Can partition a problem into smaller pieces
• Changes to a layer affect only a few layers
• Layers can be used interchangeably
• Reuse is supported

8
Implementing layered Systems

• We use Buschmanns Layers pattern
• Iterative process in general (yo-yo)
• Approximately 10 steps
• Other (Gamma) patterns may be used
• Approach is reusable (RT UML, component
  technology)

9
Some Definitions

• A task is a responsibility of a given layer
• A service is a set of functions offered by a
  layer
• We speak of service layering
• Each layer has interface functions
• A layer can be implemented as a Black Box or
  White Box

10
More on Services

• Each layer can be viewed as a virtual machine
• A service is a programmable facility of a virtual
  machine
• Examples of services DB, comm, UI

11
What is inside a Layer?

• A layer populated by modules (e.g. objects)
• Determine how to access module interfaces
• Two main possibilities
• 1 ability to access all objects (White Box)
• 2 create a contact for all modules (Black Box)

12
What is a Black Box?

• Layer N is a black box for layer N 1
• Design a flat interface that offers layer Ns
  services
• This can be achieved by the Façade pattern
• Necessitates introduction of a Façade object

13
Consequences of Black Box Approach

• Supports system evolution
• Can support multiple interface implementations
  (see Bridge pattern)
• May not be the most efficient approach
• Adds to project time

14
What is a White Box?

• Layer N 1 sees internals of layer N
• Upper layer may access modules in layer N
• Introduces explicit coupling
• Compromise gray box

15
What is a Gray Box?

• Something between White and Black!
• Layer N 1 knows number of components in layer N
• Each component is addressed separately
• However, it does not know about component
  internals

16
Consequences of White Box Approach

• Relatively easy to implement
• Incremental development
• Large maintenance costs
• Low reusability levels

17
Levels of Information Hiding
18
Layers Steps Part I

• 1 Determine abstraction criteria for task
  grouping
• 2 Determine the number of abstraction levels
• 3 Name layers and assign tasks to them
• 4 Specify layers services
• 5 Refine the layering

19
Abstraction Criteria

• Most difficult step during layering process
• Determine the different tasks
• Then groups tasks into layers
• Iterative process
• OOA use cases are of help here

20
ExamplePAC Model

• Three layers and three major tasks
• Task 1 Interactions with external environment
• Task 2 Business objects and logic management
• Task 3 Communication with other agents

21
Number of Abstraction Levels

• Each abstraction level corresponds to 1 layer
• Can split a layer into 2 layers
• Layers can be combined
• Associated advantages and disadvantages

22
ExamplePAC

• Three layers (P, A, C)
• Correspond to UML (B,E,C) pattern
• Sufficient regime for many applications
• In some cases we can split A into 2 layers
• Then get a 4-layer regime

23
LayersNames and Responsibilities

• Highest layer is overall system task
• Other tasks are helpers
• Lower layers provide an infrastructure
• Higher layers use services of lower layers
• Demands experience and foresight

24
ExamplePAC

• Layer 1 SensorUnit (interaction with
  environment)
• Layer 2 ModelledEntity (objects of interest)
• Layer 3 Controller (dispatching/notification)

25
Services of Layers

• High-level description of what a layer offers to
  upper layers
• Keep services distinct
• Locate more services in higher layers
• This reduces programmer cognitive overload

26
Layer Refinement

• Iterate over steps 1 to 4
• Combination of top-down and bottom-up approaches
• Be careful not to destroy strict layering

27
ExampleMoving from PAC to Agent Technology

• Agent technology uses a number of layered models
• Can be seen as an extension of the OO model
• A 4-layer regime is common

28
Prototypical 4-layer Model

• Level 1 World interface layer (sensors)
• Level 2 Behavioural layer (reactive objects)
• Level 3 Planning layer (algorithms, proactive
  objects)
• Level 4 Communication layer (group planning,
  communication with other agents)

29
Layers Steps Part II

• 6 Specify an interface for each layer
• 7 Structure individual layers
• 8 Specify communication between layers
• 9 Decouple adjacent layers
• 10 Design an error-handling strategy

30
Layer Interfaces

• Problem of finding interfaces for each layer
• Differences for white, black and gray boxes
• Sequence diagrams help here
• Possible to define and discover standard
  interfaces

31
Layer Structure

• Objective is to structure the internals of each
  layer
• Break a layer into finer components
• Gamma patterns are useful at this level
• Finer-grained structures

32
ExamplePAC

• Bridge support multiple implementations of a
  layer interface
• Composite complex aggregate objects
• Strategy dynamic interchange of algorithms in a
  layer
• State implementing state machines in an object

33
Using Bridges in Layers
34
Inter-layer Communication

• Determines how layers exchange information
• Precondition is that they know each other in
  some way
• Choice depends on a number of factors

35
Determining the best Choice

• Loose coupling (callbacks, implicit invocation)
• Efficiency (peer-to-peer model)
• Ability to switch at configuration time or
  run-time

36
Decouple adjacent Layers

• Optimisation step, many options
• Two-way or one-way coupling
• Callbacks help one-way coupling
• Use of C abstract classes
• Use of Bridge pattern

37
Error-handling Strategy

• Really a separate design/analysis issue
• Has a major performance impact on layered systems
• Handle error in current layer or hand it off to
  next layer?
• Rule handle errors at lowest possible layer

38
ExamplePAC

• P hardware errors (no response, heavy response)
• A emergency requests
• C notification errors

39
Advantages of Layering

• Reuse of layers
• Support for standardisation
• Dependencies are kept local
• Exchangeability of layers (via Bridge)

40
Disadvantages of Layering

• Cascades of changing behaviour
• Lower efficiency
• Unnecessary work
• Correct granularity of layers. What is it?

41
Layering and PAC last Remarks

• Similarities (levels of increasing abstraction)
• PAC structure is a tree of PAC nodes
• Layers is a vertical line of nodes
• Each PAC node consists of three components
• Layers does not prescribe how many layers to
  create

42
ExampleSteam-Boiler Problem

• Well-known prototype problem
• Objective here is to show how layers are
  implemented
• Knowing what was done allows us to improve the
  code quality and flexibility
• Three layers in general (based on PAC)
• We concentrate on Delivery agent

43
Delivery

• Responsible for producing heat and cold
• Realised by physical actuators
• Knows about provision of services
• 3-layer agent

44
Abstraction Criteria

• Desire to distance system from physical hardware
• Locate interactions with hardware in one layer
• Another layer knows what service is needed and
  what it can provide
• Upper layer is responsible for communi-cating
  results and acknowledgements

45
Layer Names and Tasks

• Delivery 2-way dispatching/notification
• ActuatorUnit current service needs and resources
• Actuators Physical heating/cooling units
• Names can be generalised (later)

46
Services

• Each layer provides services to upper layer
• Define service-access points (SAPs) and service
  provision points (SPPs)
• SAP and SPP are closely related
• SAP is upper part, SPP is lower part
• SAP and SPP ensure that layers are uncoupled

47
Services

• ActuatorControl heat and cold regulation levels
• Actuators heat and cold regulation
• Delivery service requests
• No layer refinement

48
Interfaces for Layers

• C used
• Interface functions based on sequence diagrams
• White box approach
• Tight coupling between layers (call and return
  mechanism)

49
Inter-layer communication

• Realised by function calls
• Layers know address of upper and lower neighbours
• Return and call all action starts in Mediator
• We can call it a pull model

50
Decoupling Layers

• Not done in this version of the software
• Use of C inheritance and Event classes enhances
  loose coupling
• ? use Command pattern to pass functions from
  layer to layer

51
Error Handling

• All events (including errors) are modelled by
  Event classes
• Specialised events per agent
• All handling takes place in Mediator
• Centralised control (more dependencies)

52
ExampleFinancial Services Architecture

• Provides access to financial services from an
  application
• Ability to communicate with various service
  providers
• Precondition no code change

53
Architecture

• 3 main layers
• XFS API used by application
• XFS SPI interfaces to specific service providers
• XFS Manager maps API calls to appropriate
  service provider

54
XFS Architecture
55
Remarks on Communication

• API calls can be synchronous or asynchronous
• SPI calls are always asynchronous
• Service provider entry point is always local
• Device or service (final target) may be remote

56
Responsibilities of Service Providers

• Translate generic service requests to
  service-specific requests
• Request routing
• Arbitrate access by multiple apps to a single
  service or device
• Manage hardware interfaces to services or devices
• Manage asynchronous nature of services and devices

57
API Functions

• Basic StartUp/CleanUp, Open/Close, Lock/Unlock
• Administration functions (e.g. device init)
• Specific commands (e.g. request
  device/service-specific functions)
• SPI functions kept as close as possible to API
  functions