Architectural Styles

1
Architectural Styles

• Csci501 Software Architecture
• Fall 2008

2
Design Representations

• Main Design Representations can be
• Constructional form
• The focus is on using structuring forms provided
  in PLs
• .h header files, html, xml, class etc
• Behavioral forms
• The focus is on operations
• Finite-state machines (FSM)
• Functional Forms
• What a system does
• Data Flow Diagram (DFD)
• Data-modeling forms
• The detailed nature of Data
• Entity Relationship Diagrams (ERD)

3
Notations

• Form of notations
• Text (e.g. NL)
• Simplicity (good)
• Very ambiguous
• Diagram (e.g. UML)
• Simplicity (good)
• Natural limit (bad)
• Formal methods (e.g. Z)
• Complexity (bad)
• Analyzability (good)

4
Architectural styles

• Architectural style
• Used extensively in well-established engineering
• Shared vocabulary of design to define a family
  systems in terms of structural organization
• Can be instantiated or tailored
• E,g., Client/Server
• Some associated with specific design (e.g.,
  dataflow, or OOD)
• Some associated with a specific classes of
  systems (e.g., compiles)

5
Elements of an architectural style

• Components types
• Locus of computation
• Connectors types
• Locus of communication, coordination, and
  cooperation
• Configurations
• allowable structural patterns
• Constraints
• Essential invariants

6
Categories of architectural styles

• Selection of specific styles depends on
• The types of components/connectors that are used
  in the style
• The ways in which control is shared, allocated,
  and transferred among the components
• The way by which data is communicated
• The way by which data and control interact
• Advantages/disadvantages of that style
• The invariants of the style?

7
Data Flow

• Main Properties
• reuse and modifiability
• System is a succession of transformations on
  pieces of input data

8
Data Flow Variations

• Variations include
• Batch Sequential
• Component are independent programs
• Execute and complete one after the other
• Data transmitted as a whole between steps.
• Pipes-and-Filters
• incremental transformation of data by successive
  components.
• Each component has a set of inputs/outputs
• Each Component reads/writes stream of data using
  inputs/outputs

9
Pipes and Filters

• Components
• Filters (components)
• read a stream of data on its inputs and produce a
  stream of data on its outputs.
• Pipes (connectors)
• transmit output produced by filters to other
  filters as input.

10
P/F Invariants

• Invariant
• filters must be stand alone program (i.e., do not
  share information with other filter)
• Do not know the ID of their up/down stream
  filters
• Does not enforce particular order

11
P/F specialization

• Pipelines
• Restrict topologies to linear sequences of
  filters
• Bounded pipes
• Restrict the amount of data that can be reside on
  a pipe
• Typed pipes
• Require the data passed between two filters
  having a proper types

12
Examples of P/F

• Unix shell
• Traditional compilers

13
Example Compiler
ASCII program text
Lexical Analyzer
token stream
Syntax Analyzer
abstract syntax tree
Semantic Analyzer
program
Intermediate Code Generator
optimized program
14
P/F Disadvantages

• Sharing state information is expensive or
  inflexible
• Efficiency using parallel processing
• Cost of transferring/reformatting data between
  filter may be high comparing to the cost of
  computation
• Batch semantics
• Synchronization issue
• Synchronization of filters and pipes (deadlock,
  buffer overflow, etc.)
• Not good at handling interactive applications
  (GUI)

15
Call and Return architectures

• Main Properties
• modifiability and scalability.
• Variations
• Main Program and Subroutine
• hierarchically decompose a program
• each component get control and data from its
  parent and pass it to children.
• Remote procedure Call Client/Server
• Main Program and Subroutine where parts are
  distributed on a network.
• Increase performance (multiple processors).
• Object Oriented
• Layered

16
Object-Oriented/Abstract Data Style

• Main Properties
• more natural modelling of real world
• Reuse and localization
• Abstraction, encapsulation, information hiding
• Data and operations are encapsulated in
  objects/classes.
• Objects
• maintain data integrity
• hide data representation
• communicate through messages

17
Layered Hierarchies

• Main Properties
• Abstractions,
• Design for change
• dependencies are kept local
• exchangeability
• reuse
• portability
• Context
• a large system that requires decomposition
• Components
• Hierarchical organization in layers
• Each layer provides services to the one outside
  it
• Each layer acts as a client to the layer inside
  it
• Some cases all layers have access to all or some
  other layers
• Other systems constrain access only to close
  layers
• Connectors
• defined as protocols between layers.

18
Layered Hierarchies (Summary)

• Advantages (good)
• abstraction levels.
• evolution
• easy to add and/or modify a current layer
• reuse
• standardization
• Disadvantages (bad)
• System performance
• Cascades of changing behaviour
• Difficulty to model (structure or find the right
  level of abstraction)

19
Data-centred style (repositories)

• Goals
• scalability (new clients/data easily added)
• Separation of concerns
• Components
• Central data store - current state.
• Independent components operating on the data
  store.

20
Possible Variations

• Variations
• Blackboard
• state of central data store triggers for
  selecting process to execute
• Traditional data base
• type of transaction triggers selection of process
  to execute.

21
Blackboard architecture

• Context and applicability
• Demands complex data interpretation
• (signal processing, speech/pattern recognition)
• involves shared access to data with loosely
  coupled agents

22
Blackboard architecture Main Components

• Blackboard
• Manage central data
• Knowledge Sources
• evaluate their applicability
• compute a result
• update Blackboard
• Control
• monitor Blackboard
• schedule Knowledge Sources activity

23
Other Examples

• HASP/SIAP
• To detect enemy submarines from sonar signals
• CRYSALIS
• Infer 3D structure of protein molecules from
  X-ray diffraction data.
• TRICERO
• Monitors aircraft activities.

24
Distributed Processes

• Different possible topologies (ring, star, etc)
• Include
• Client/Server (C/S)
• Service-Oriented Architectural Style
• Broker architecture
• Used to structure distributed software
• Decouples and Coordinates components that
  interact by RPC
• CORBA
• Peer-to-peer (P2P)

25
Client/Server

• Components
• Client
• requests information from a server
• knows the server identity
• Server
• responds to the requests from clients
• doesn't know the clients' identity

26
Client/Server

• Advantages
• users only get information on demand
• design addresses presentation details
• different ways to view the same data
• Disadvantages
• demands more sophisticated security and systems
  management
• applications development requires more resources
  to implement and support
• Distribution Problems

27
Variations Two tier Client/Server architectures

• Processing management split between user system
  interface environment and database management
  server environment.
• Tier 1 user system interface
• In user's desktop environment
• Tier 2 database management services
• In a server

28
Two tier Client/Server architectures More

• Problems
• performance deteriorate when number of clients is
  large (gt100 users)
• flexibility and choice of DBMS for applications
  reduced (by processing management at server level
  stored procedures)
• limited flexibility in moving (repartitioning)
  program functionality from one server to another

29
Three tier Client/Server architectures

• Tier 1 user system interface
• Tier 2 middle-tier (broker) provides
• process management (business logic and rules
  execution) and
• functions (e.g queuing, application execution,
  and database staging)
• Tier 3 database management services

30
Three tier architectures middle tier

• Centralizes process logic
• Improve performance, flexibility,
  maintainability, reusability, and scalability
• changes must only be written once and placed on
  the middle tier server to be available throughout
  the systems
• distributed database integrity more easily
  enforced
• access to resources based on names

31
Process control

• Continually running system used for process
  control
• Examples
• temperature control system
• nuclear power plant control system
• etc

32
Process control

• Variables
• Process variables
• properties of the process that can be measured
• value obtained by sensors
• Controlled variables
• process variables that must be controlled by
  system
• set point (Reference/target value )
• desired value for a controlled variable

33
Process control

• Purpose
• Maintain controlled variables value at or near
  target values

34
Process control

• Open loop system
• doesn't use information about process variables
  to adjust the system.
• rarely suited to physical processes in the real
  world.
• Closed loop system
• uses information about process variables to
  manipulate process variables in order to
  compensate for variations in process variables
  and operation conditions.

35
Process control

• Drawbacks - One must decide
• what variables to monitor
• what sensors to use
• how to calibrate them
• how to deal with timing of sensing and control

36
Process control

• Shaw and Garlan recommend divide the system in
  three parts
• Computational elements
• process definition (include mechanisms for
  changing process variables)
• control algorithm (how to decide when and how to
  make changes)
• Data elements (process variables, set point)
• Control loop scheme (open-loop, closed-feedback,
  closed-feedforward).

37
Domain-specific software architectures

• Library of different architecture styles
• Provides information for new systems in the same
  domains
• Avoids rework on already known assumptions and
  relationships

38
Heterogeneous Architectures

• It is difficult to build a complex system
• Single style
• Or single notation
• Single model
• Need blend of
• Styles
• Notations
• models

39
Example 1 Vertical

• Event system is a blackboard, but, when is
  decomposed, the component shows a layered style

40
Master-Slave

• Provide services that can solved using divide
  and conquer principle
• Work decomposed into sub-tasks
• Support
• Fault tolerance
• Concurrent computation
• Computational accuracy

41
M/S Good

• Exchangeability and extensibility
• Separation of concerns
• Efficiency using parallel computation
• Reliability
• Availability

42
M/S Bad

• Not always feasible (very costly)
• Partition work
• Multiple copy of data
• Access control Coordination
• Security
• portability

43
Acknowledgement/references

• Pattern Oriented Software Architecture by Frank
  Buschmann, et al. (1996)
• Software Architecture Perspective on an Emerging
  Discipline by Mary Shaw/ David Garlan (1996)
• Software Architecture in Practice, 2nd edition by
  Bass et al. (2003)
• Software Design, 2nd edition by David Budgen
  (2003)
• And more