Architectural Design - PowerPoint PPT Presentation


PPT – Architectural Design PowerPoint presentation | free to download - id: 1fb5e0-MGZlM


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Architectural Design


Architectural design represents the most abstract level of design ... Automotive Parts: repository. Client Interface. Invoice Subsystem. Supplier Interface ... – PowerPoint PPT presentation

Number of Views:298
Avg rating:3.0/5.0
Slides: 24
Provided by: CalumW8
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Architectural Design

Architectural Design
Andrew Ireland School of Mathematical Computer
Sciences Heriot-Watt University Edinburgh
  • Motivations
  • Structure
  • Control
  • Decomposition

  • 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!
Architectural Activities
  • Systems structuring
  • Subsystems
  • Communication between subsystems
  • Control modelling
  • Subsystems and control
  • Subsystem decomposition
  • Subsystems and modules
  • Module interconnections

Repository Model
Client Interface
Invoice Subsystem
Automotive Parts repository
Supplier Interface
Stock Subsystem
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
  • 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

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

Client-server Model

Client 1
Client M
Server 1
Server N

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

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

Layered Model
User Processes
Service Processes
Device Drivers
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

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

Centralized Control
main program
subroutine A
subroutine Z

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

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

process 3
process N
manager model
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

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
  • Example event-driven models
  • Broadcast control
  • Interrupt-driven control

Broadcast Control

Event and message handler
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
  • Advantages
  • Ease of system evolution
  • No need for explicit identification for
  • 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

Interrupt-driven Control

interrupt vector
Handler 1
Handler 2
Handler N

Process N
Process 1
Process 2
Interrupt-driven Control
  • System involves pre-defined kinds of interrupts,
    i.e. events that cause processing to be
  • 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

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

  • 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