Architectural Design

1
Architectural Design
Andrew Ireland School of Mathematical Computer
Sciences Heriot-Watt University Edinburgh
2
Outline

• Motivations
• Structure
• Control
• Decomposition

3
Motivations

• Architectural design represents the most abstract
  level of design
• Involves the identification of subsystems and
  their interconnections
• Just like in designing a building or a bridge,
  sound architectural decisions are crucial to the
  success of a project

a bad architecture cant be saved by good
construction methods!
4
Architectural Activities

• Systems structuring
• Subsystems
• Communication between subsystems
• Control modelling
• Subsystems and control
• Subsystem decomposition
• Subsystems and modules
• Module interconnections

5
Repository Model
Client Interface
Invoice Subsystem
Automotive Parts repository
Supplier Interface
Stock Subsystem
6
Repository Model

• The repository model is appropriate when there
  exists a clear producer/consumer relationship
  between subsystems and data, e.g. command and
  control, inventory management, information
  management
• The repository imposes a data model that all
  subsystems will have to operate with
• Advantages
• Efficient mechanism for sharing large amounts of
  data between subsystems no need for data to be
  communicated between subsystems directly
• Data producers (subsystems) are decoupled from
  the needs of data consumers (subsystems)
• Security and archive issues are centralized

7
Repository Model

• Advantages (contd)
• Having a clearly defined data model makes
  integration of new subsystems a well defined task
  
• Disadvantage
• Imposing a single data model on all systems may
  impact on performance, as well as adaptability,
  i.e. integration of new subsystems
• Evolution may be impeded by the use of a standard
  data model, i.e. converting to a new standard,
  may be expensive and may lead to the lose of data
  (data warehousing)
• Distributing a repository model over multiple
  machines gives rise to additional challenges,
  i.e. dealing with redundancy and inconsistencies
  

8
Client-server Model

Client 1
Client M
Network
Server 1
Server N

9
Client-server Model

• A distributed systems model contains a
• set of servers (subsystems) providing services
• set of clients (subsystems) which know the
  identification of the services
• network which allows clients to access services
  via remote procedure calls
• Typically data is also distributed across the
  system with no standard data model imposed

10
Client-server Model

• Advantages
• Ease of system evolution, e.g. new servers can be
  integrated incrementally and existing servers can
  be upgraded transparently
• Having no standard data model provides
  opportunities for efficiency gains
• Disadvantages
• Having no standard data model may give rise to
  unforeseen integration issues
• Security and archiving becomes a distributed
  problem

11
Layered Model
User Processes
Service Processes
Device Drivers
Kernel
12
Layered Model

• Each layer represents an abstract machine,
  providing a well defined set of services
• Advantages
• promotes an incremental style of development
• promotes portability and change
• Disadvantages
• crossing cutting services, e.g. file handling, do
  not fit the layered model
• multiple layers may lead to performance issues

13
Control Models

• Centralized control
• A single subsystem is responsible for controlling
  the operation of all the other subsystems
• Other subsystems may be given control on a
  temporary basis
• Event-based control
• Control is distributed, each subsystem is
  responsible for its actions
• Subsystems react to external events generated by
  other subsystems or the operational environment,
  e.g. sensor input

14
Centralized Control
main program
subroutine A
subroutine Z

subroutine Z.1
subroutine Z.N
subroutine A.N
subroutine A.1


call-return model
15
Centralized Control
process 1
process 2
manager process

process 3
process N
manager model
16
Centralized Control

• Call-return model
• Hierarchical subroutine model
• Control is passed down through the hierarchy
• Applicable to sequential systems
• Less flexible and thus easier to analyse
• Manager model
• Central control process which provides
  coordination between subprocesses
• Processes are executed in parallel
• Applicable for concurrent systems
• More flexible and thus harder to analyse

17
Event-driven Control

• System behaviour is driven by events, e.g.
• external stimuli - sensors
• user interactions - mouse clicks, key strokes
• process communications - messages from process
  threads
• Example event-driven models
• Broadcast control
• Interrupt-driven control

18
Broadcast Control

subsystem-1
subsystem-N
Event and message handler
19
Broadcast Control

• Subsystems are associated, or registered, with
  specific events subsystems decide which events
  to react to
• Event message handler broadcasts events to
• All subsystems OR
• Only those subsystems registered for a given
  event
• Advantages
• Ease of system evolution
• No need for explicit identification for
  subsystems
• Disadvantages
• Potential conflicts arising from multiple
  responses to events
• Not appropriate for hard real-time systems, i.e.
  systems which require a response within a fixed
  time frame

20
Interrupt-driven Control

interrupt vector
Handler 1
Handler 2
Handler N


Process N
Process 1
Process 2
21
Interrupt-driven Control

• System involves pre-defined kinds of interrupts,
  i.e. events that cause processing to be
  interrupted
• Each interrupt is mapped onto a special area of
  memory known as the interrupt vector
• The interrupt vector references interrupt
  handlers, hardware ensures that control is passed
  to the relevant interrupt handler when an
  interrupt occurs a handler will typically start
  or stop processes
• Advantages
• Good for hard real-time systems, i.e. fast
  predictable response times
• Disadvantages
• Hard to program and validate
• Limited by hardware, i.e. upper bound on
  interrupt vector

22
Subsystem Decomposition

• Subsystems typically require further
  decomposition, i.e. decomposition into modules
• This level of decomposition lies on the boundary
  of architectural design
• Two principal decomposition approaches
• Data-flow
• Object-oriented
• Both are expanded upon in the next couple of
  lectures

23
Summary

• Learning outcomes
• Motivations for architectural design
• Systems structuring and control
• Recommended reading
• M. Shaw, D. Garlan, Software Architecture
  Perspectives on an Emerging Discipline,
  Prentice-Hall 1996
• I. Sommerville, Software Engineering,
  Addison-Wesley 2007