Software Architecture

1
Software Architecture

• What is a Software Architecture?
• High-level description of a complex software
  system
• Includes both diagrams and text
• Simplified diagrams often used for marketing
  (e.g. Apples OS X)

2
Software Architecture

• All systems have an architecture, but what are
  the benefits of designing (and specifying) one?
• Stakeholder communication
• System analysis (reasoning about non-functional
  requirements)
• Reuse
• Project management (concurrent development)

3
Software Architecture

• What is a Software Architecture?
• Answers questions like
• What are the primary subsystems?
• What is the division of labor?
• How will the subsystems communicate?
• What will the subsystems communicate?

4
Subsystems
A subsystem is a system in its own right whose
operation does not depend on services provided by
other systems. Subsystems are composed of
modules, and have defined interfaces used for
communication with other subsystems.
Sommerville, p. 217

• .
• Design/implementation often delegated to
  different engineering teams
• Development can proceed in parallel
• Separation of responsibility
• Minimal inter-subsystem communication

5
Software Architecture

• Subsystem breakdown guided by
• Performance
• Minimize communication among subsystems
• Security
• Use layered architecture, with critical assets in
  inner layers
• Safety
• Isolate safety-critical components
• Availability
• Redundancy, replication of services
• Maintainability
• Subsystems modules with self-contained components

6
Software Architecture

• Software System Architecture
• System structuring
• Control models
• Modular decomposition
• Domain-specific architectures

7
Structural Models

• The Repository
• The Client-Server Model
• The Abstract Machine

8
The Repository Model

• Shared data is stored in centralized location
  (the repository subsystem), and accessed by
  various (other) subsystems
• Shared data is passed from one subsystem to the
  next (pipeline architecture)
• E.g., compiler

9
CASE toolset architecture
10
The Repository Model

• Characteristics
• Sharing model is published as repository schema
• Pros
• Efficient way to share large amounts of data
• Data integrity localized to repository module
• Cons
• Subsystems must agree (i.e., compromise) on a
  repository data model.
• Schema evolution is difficult and expensive
• Distribution can be a problem

11
Client-Server Architecture

• Subsystems are viewed as independent processes.
• Set of stand-alone servers which provide specific
  services such as printing, data management, etc.
• Set of clients which call on these services.
  Servers can be clients of other servers.
• Communication network

12
Client-Server Architecture Film and picture
library
13
Client-Server Architecture Characteristics

• Pros
• Makes effective use of networked systems. May
  require cheaper hardware
• Easy to add new servers or upgrade existing
  servers
• Availability (redundancy) may be straightforward
• Cons
• Data interchange can be hampered by different
  data layouts
• Communication may be expensive
• Data integrity functionality must be implemented
  for each server
• The naming problems

14
Abstract Machine Model

• Organises the system into a set of layers (or
  abstract machines) each of which provide a set of
  services
• Supports the incremental development of
  sub-systems in different layers. When a layer
  interface changes, only the adjacent layer is
  affected
• Cant model all systems this way

15
Abstract Machine Model

• Examples
• Version Management System
• Operating System (e.g., Linux)
• Runtime Language Environments (e.g., Java)

16
Abstract Machine Model Version management system
17
(No Transcript)
18
Control Models

• How subsystems behavior is coordinated
• Orthogonal to system structure
• Two broad categories
• Centralized control
• Master subsystem
• Event-based control
• Each subsystem able to respond to external events

19
Control Models Centralized Control

• Master subsystem has responsibility for managing
  execution of (other) subsytems
• Call-Return Model
• Manager Model

20
Control Models Centralized Control

• Master subsystem has responsibility for managing
  execution of (other) subsytems
• Call-Return Model
• Subsystems invoked using traditional
  subroutine/function calls
• Applicable in sequential execution only
• Manager Model

21
Call-Return Model (figure)
22
Control Models Centralized Control

• Master subsystem has responsibility for managing
  execution of (other) subsytems
• Call-Return Model
• Manager Model
• Subsystems run as separate processes
• Manager starts/suspends/stops processes
• Implied in concurrent systems, can be useful in
  sequential ones

23
Control Models Event-Based Control

• No master controller
• Subsystems react to external events
• Subsystems can signal events to others
• Specific examples
• Spreadsheet (cell state changes)
• Soar, Linda (AI-inspired production systems)
• Ethernet

24
Event-Based ControlBroadcast Models

• Event is broadcast to all subsystems
• Appropriate subsystem responds
• Conflict resolution?
• Event Handler
• Subsystem can register interest in particular
  events
• Handler passes off to registered subsystem
• Reduces overhead on uninterested subsystems

25
Event-Based ControlBroadcast Models

• Pros
• Simple to evolve (add/remove/change event
  handlers)
• Subsystems dont need to know others by name
• Cons
• Caller doesnt know if/when event will be handled
• Conflict resolution

26
Event-Based ControlInterrupt-Driven Models

• Preferable to broadcast models for real-time
  reaction
• Interrupt handlers
• Hardware supported
• Triggered by raising of interrupt event
• Assume control of subsystems
• E.g. air-bag deployment fire-control systems

27
Event-Based ControlInterrupt-Driven Models

• Pros
• Allows for fast responses context switches
• Cons
• Complex to program
• Difficult to validate (reproducing timings)
• Number limited by hardware

28
Modular Decomposition

• Decomposition of subsystems into modules
• Models include
• System architectural models
• Object-oriented model(to be discussed in future
  lecture)
• Data-flow model

29
Modular DecompositionData-Flow Model

• Data flows through transformation stages (a.k.a.
  pipes and filters)
• Sequential flow batch processing model
• Examples
• Regular invoice/bill processing
• Bank statement generation
• Report generation

30
Domain-Specific Architectures

• Can be useful to frame, guide architectural
  design for a specific domain
• Generic Models
• Generalized architecture of real applications in
  domain
• Often proprietary (e.g. product-line
  architectures)
• Reference Models
• Idealized architecture for an application domain

31
Generic ModelsExample Compiler (Data-flow)
32
Generic ModelsExample Compiler (Repository)
33
Reference Models Example The OSI Networking
Model

• OSI Open Systems Interconnection
• A layered model for communication systems
  (similar to Abstract Machine Model)

34
Domain-Specific Architectures Example The OSI
Networking Model

• The Seven Layers
• 7. Application
• 6. Presentation
• 5. Session
• 4. Transport
• 3. Network
• 2. Data Link
• 1. Physical

35
Software Architecture Key Points

• Software architect responsible for deriving a
  structural system model, a control model and a
  sub-system decomposition model
• Large systems rarely conform to a single
  architectural model
• System decomposition models include
• repository models
• client-server models
• abstract machine models

36
Software Architecture Key Points

• Control models include
• centralized control models
• event-driven models
• Modular decomposition models
• data-flow models
• object-oriented models
• Domain-specific architectural models
• abstractions of existing systems
• idealized reference models