Architectural Design - PowerPoint PPT Presentation

Loading...

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



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Architectural Design

Description:

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: http://www.macs.hw.ac.uk
Category:

less

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

Title: 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
About PowerShow.com