CS 425/625 Software Engineering

Architectural Design
Based on Chapter 11 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8th Ed., Addison-Wesley, 2006 and on the Ch11 PowerPoint presentation available at the books web-site:
www.comp.lancs.ac.uk/computing/resources/IanS/SE6/Slides/index.html

October 15, 2008

1 / 26

Outline

Introduction System Organization Modular Decomposition Control Styles Reference Architectures

2 / 26

Introduction.

Architectural (high-level) design = the process of establishing the subsystems of a larger software system and defining a framework for subsystem control and data communication Software architecture = the output of the high-level design process Defining and documenting the software architecture provides support for:
Stakeholder

communication System analysis Large-scale software reuse

3 / 26

.Introduction

The overall system architecture influences the systems:

Performance Security

Safety
Availability Maintainability

4 / 26

..Introduction..

Distinction between subsystem and module:

Subsystem

= larger part of the system with quasiindependent operation; depends little on other subsystems services, contains other subsystems and modules as well as interfaces for communicating with other subsystems Module = non-independent system component that provides services to other modules; usually makes use of other modules services and contains simpler components

5 / 26

Introduction.

Common high-level design activities:

System

structuring (system organization): identification of sub-systems and their communication paths Modular decomposition: identification of modules and module interconnection within each subsystem Control modeling: determination of control connections between subsystems (modules)

6 / 26

.Introduction

Types of architectural design models:

Static

structural models Dynamic process models Interface models Relationship models Distribution models

7 / 26

System Organization..

System organization (system structuring) is focused on identifying subsystems and their communication links Communications between subsystems involve both data and control Block diagrams can be used for describing the systems structure The systems architecture can be shown using more specific structural models, e.g.:

8 / 26

Repository model Client-server model Layered model

.System Organization.

The repository model shows a systems architecture centered around a shared database The client-server model is a distributed, network model that describes how operations and data are distributed across several processing units. Some of these units are servers, other are clients The layered model (the abstract machine model) depicts the system as a series of layers, each layer representing an abstract machine and having assigned a subsystem

9 / 26

..System Organization

Example of a structural model depicted using a block diagram: a packing robot system [Fig. 11.1, SE-8]
Vision system

Object identification system

A rm cont roller

Gripper controller

Packaging selection system

Packing system

10 / 26

Conveyor controller

System Organization..

Example of repository model for system architecture: a CASE toolset [Fig. 11.2, SE-8]
Design editor Code generator

Design translator

Project repository

Program editor

Design analyser
11 / 26

Report generator

.System Organization.

Example of client-sever architecture: a movie and picture library [Fig. 11.3, SE-8]

12 / 26

..System Organization

An abstract machine model: a version management system [Fig. 11.4, SE-8]

Configuration management system layer

Object management system layer

Database system layer

Operating system layer

13 / 26

Modular Decomposition..

Modular decomposition means dividing each subsystem in modules and identifying interconnections between modules Models described previously can be applied here as well (a subsystem is, in fact, a system, and the distinction between a subsystem and a module is relative) Styles that may be used for decomposition:

Object-oriented decomposition: a subsystem consists of several communicating objects Function-oriented pipelining: functional modules are identified, together with data transfer paths

14 / 26

.Modular Decomposition.

Partial object model of an invoicing system [Fig. 11.5, SE-8]

Customer Receipt invoice# date amount customer#

customer# name address credit period

Invoice invoice# date amount customer issue () sendR eminder () acceptPayment () sendR eceipt ()

Payment invoice# date amount customer#

15 / 26

..Modular Decomposition

DFD of an invoicing system [Fig. 11.6, SE-8]

Issue receipts Read issued invoices Identify payments Find payments due Invoices Payments

Receipts

Issue payment reminder

Reminders

16 / 26

Control Styles..

Control models emphasize control flow among subsystems Two general approaches:
Centralized

control: a single subsystem (central controller) has the control responsibility of the entire system; it may defer control to other subsystems but the control must be returned to the central controller

Call-return model (top-down subroutine model) Manager model (applies to concurrent systems, in which several processes run in parallel)

17 / 26

.Control Styles.

Two general approaches (continued):

Event-based

control: each subsystem has control responsibilities; they respond to events generated by the environment and/or other subsystems

Broadcast models: an event is dispatched to all subsystems Interrupt-driven models: make use of interrupt handlers; typical to RTS

18 / 26

..Control Styles...

The call-return control model [Fig. 11.7, SE-7]

Main program

Routine 1

Routine 2

Routine 3

Routine 1.1

Routine 1.2

Routine 3.1

Routine 3.2

19 / 26

Control Styles..

Example of a centralized control model: an RTS [Fig. 11.8, SE-7]

Sensor processes Actuator processes

System contr oller

Computation processes

User interface

Fault handler

20 / 26

.Control Styles.

Control model with selective broadcasting [Fig. 11.9, SE-7]

Sub-system 1

Sub-system 2

Sub-system 3

Sub-system 4

Event and messa ge handler

21 / 26

..Control Styles

Example of interrupt-driven control model [Fig. 11.10, SE-7]

Interrupts

Interrupt vector

Handler 1

Handler 2

Handler 3

Handler 4

Process 1
22 / 26

Process 2

Process 3

Process 4

Reference Architectures

A domain-specific architecture is characteristic to a particular application domain; it proposes a common architectural structure that can be used across applications within that particular domain Note that, generally, in architectural design various design models can (and usually need) be applied in combination

23 / 26

.Reference Architectures..

Main categories:
Generic

models: models extracted from real systems that provide a common architectural framework for new applications within the domain (e.g., compiler design) Reference models: more abstract models that communicate commonly used domain and design concepts; derived from studying the application domain (e.g., the Open Systems Interconnection [OSI] reference model)

24 / 26

..Reference Architectures.

Generic repository model of a language processing system [Fig. 13.13, SE-7]

Lexical analyser Syntax analyser Semantic analyser

Prettyprinter

Abstract syntax tree

Grammar definition

Optimizer

Editor

Symbol table

Output definition Repository

Code generator

25 / 26

Reference Architectures

Example of reference architecture: the OSI model [Fig. 11.11, SE-7]

7 6 5 4 3 2 1 Application Presentation Session Transport Network Data link Physical Network Data link Physical Communica tions medium Application Presentation Session Transport Network Data link Physical

26 / 26