Architecture

1
Architecture Layers, in particular

• ECEN 5543 / CSCI 5548 SW Eng of Standalone
  Programs
• University of Colorado, Boulder

2
Design Pattern Roots

• Text describes various arch. patterns as codified
  learning
• Older techniques include
• Levels of Abstraction
• Integrated Top-Down
• Information Hiding
• Overall principles of
• abstraction
• structure
• verification
• modularity
• business influence and impact -- extensibility

3
POSA 1 POSA 2

• Patterns-Oriented Software Architecture, Volume
  1 A System of Patterns Frank Buschmann, Regine
  Meunier, Hans Rohnert, Peter Sommerlad John
  Wiley Sons 1996 ISBN 0471958697
• (On Amazon, 4.5 stars out of 5)
• (Volume 2 subtitle Concurrent and Networked
  Objects, Douglas Schmidt, Michael Stal, Hans
  Rohnert, Frank Buschmann, 2000)
• Patterns help you build on the collective
  experience of skilled software engineers. (1st
  sentence)

4
Patterns put you on the shoulders of Giants

• Isaac Newton famously remarked in a letter to
  Robert Hooke, dated 5 February 1676
• "If I have seen a little further it is by
  standing on the shoulders of Giants.
• (Earliest use of the metaphor is John Salisbury,
  1159)
• When Hamming received the Turing award in 1968.
  he contrasted software developers to Newton
  saying something like
• While Newton may have stood on the shoulders of
  Giants, in software development, we stand on each
  others feet.

5
What is the Layers Pattern?

• Architectural pattern that helps to structure
  applications that can be decomposed into groups
  of subtasks in which each group of subtasks is at
  a particular level of abstraction.
• What is high? What is low?
• Flow
• requests from higher layer to lower layer
• answers from lower layer to higher layer
• incoming data or event notification from low to
  high

6
Layers Arch.
7
Balance the Forces

• Late source code changes should not ripple
• Interfaces should be stable
• Interfaces may be prescribed by a standards body
• Parts of the system should be exchangeable
• Design for change!
• May be necessary to build other systems at a
  later date with same low-level issues
• Similar responsibilities should be grouped to
  help understandability and maintainability
• No standard component granularity
• Complex components may need further decomposition

8
More forces

• Crossing component boundaries may impede
  performance
• substantial amount of data transferred over
  several boundaries
• The system will be built by actual human beings
• Work must be subdivided along clear boundaries
• Architecture influences team structure and vice
  versa

9
Solution

• Structure the system into an appropriate number
  of layers
• Think of lowest level as Layer 1 highest Layer N
• This gives a conceptual view not marching
  orders regarding sequence of further design
• Within a layer, all subcomponents work at the
  same level of abstraction
• Most of what Layer J provides is composed of
  services provided by Layer J-1, combined in a
  meaningful way for the application.

10
Scenario I
11
Scenario II
12
ScenarioIII
13
Scenario IV
14
Scenario V
15
Implementation Steps

1. Define which of the abstraction criteria you will
   use
2. Determine the number of abstraction levels
   according to your criterion
3. Name the layers and assign tasks to each of them
4. Specify the services
5. Refine the layering
6. repeat steps 1-4 until natural, stable layering
   evolves
7. Finding layers is not orderly yo-yo development
8. Specify an interface for each layer

16
Implementation Steps -- continued

• Structure individual layers
• Specify communication between adjacent layers
• push/pull
• Decouple adjacent layers
• top-down J1 knows about J J can ignore J1
• bottom-up
• can use callbacks
• can decouple the upper from the lower somewhat
• Design an error-handling strategy

17
Known Uses

• Virtual Machines
• APIs
• Information systems lower layer is database
• Presentation
• Application logic
• Domain layer
• Database
• Some operating systems Windows NT

18
Benefits
19
Liabilities
20
Bibliography (cont.)

• Pattern-Oriented Software Architecture, A System
  of Patterns, Volume 1, Frank Buschmann, Regine
  Meunier, Hans Rohnert, Peter Sommerlad, Michael
  Stal, Wiley Sons, 1996, ISBN 0 471 95869 7
  often referred to as the POSA book or POSA 1
  because there are now 2 volumes.
• Go to Amazon.com and read the reviews to get a
  feel for how well respected this book is.