software architecture l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software Architecture PowerPoint Presentation
Download Presentation
Software Architecture

Loading in 2 Seconds...

play fullscreen
1 / 36

Software Architecture - PowerPoint PPT Presentation


  • 388 Views
  • Uploaded on

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. Apple’s OS X ) Software Architecture

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Architecture' - Thomas


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software architecture
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. Apple’s OS X)

Chapter 10 - System Architectures

software architecture2
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)

Chapter 10 - System Architectures

software architecture3
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?

Chapter 10 - System Architectures

subsystems
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

Chapter 10 - System Architectures

software architecture5
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

Chapter 10 - System Architectures

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

Chapter 10 - System Architectures

structural models
Structural Models
  • The Repository
  • The Client-Server Model
  • The Abstract Machine

Chapter 10 - System Architectures

the repository model
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

Chapter 10 - System Architectures

case toolset architecture
CASE toolset architecture

Chapter 10 - System Architectures

the repository model10
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

Chapter 10 - System Architectures

client server architecture
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

Chapter 10 - System Architectures

client server architecture characteristics
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

Chapter 10 - System Architectures

abstract machine model
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
  • Can’t model all systems this way

Chapter 10 - System Architectures

abstract machine model15
Abstract Machine Model
  • Examples
    • Version Management System
    • Operating System (e.g., Linux)
    • Runtime Language Environments (e.g., Java)

Chapter 10 - System Architectures

abstract machine model version management system
Abstract Machine Model Version management system

Chapter 10 - System Architectures

control models
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

Chapter 10 - System Architectures

control models centralized control
Control Models Centralized Control
  • Master subsystem has responsibility for managing execution of (other) subsytems
    • Call-Return Model
    • Manager Model

Chapter 10 - System Architectures

control models centralized control20
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

Chapter 10 - System Architectures

call return model figure
Call-Return Model (figure)

Chapter 10 - System Architectures

control models centralized control22
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

Chapter 10 - System Architectures

control models event based control
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

Chapter 10 - System Architectures

event based control broadcast models
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

Chapter 10 - System Architectures

event based control broadcast models25
Event-Based ControlBroadcast Models
  • Pros
    • Simple to evolve (add/remove/change event handlers)
    • Subsystems don’t need to know others by name
  • Cons
    • Caller doesn’t know if/when event will be handled
    • Conflict resolution

Chapter 10 - System Architectures

event based control interrupt driven models
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

Chapter 10 - System Architectures

event based control interrupt driven models27
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

Chapter 10 - System Architectures

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

Chapter 10 - System Architectures

modular decomposition data flow model
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

Chapter 10 - System Architectures

domain specific architectures
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

Chapter 10 - System Architectures

generic models example compiler data flow
Generic ModelsExample:Compiler (Data-flow)

Chapter 10 - System Architectures

generic models example compiler repository
Generic ModelsExample:Compiler (Repository)

Chapter 10 - System Architectures

reference models example the osi networking model
Reference Models Example:The OSI Networking Model
  • OSI = Open Systems Interconnection
  • A layered model for communication systems (similar to Abstract Machine Model)

Chapter 10 - System Architectures

domain specific architectures example the osi networking model
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

Chapter 10 - System Architectures

software architecture key points
Software ArchitectureKey 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

Chapter 10 - System Architectures

software architecture key points36
Software ArchitectureKey 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

Chapter 10 - System Architectures