Objectives Software Design 1 Fundamentals of Design

Preparing to load PDF file. please wait...

0 of 0
100%
Objectives Software Design 1 Fundamentals of Design

Transcript Of Objectives Software Design 1 Fundamentals of Design

ecture 11 - Software Design Overview

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

1

Software Design – 1 Fundamentals of Design
Deriving a solution which satisfies the software requirements
Hamlet Chapter 11 Additional Reading

Fall 200

Objectives
ƒ To define design ƒ To introduce the design process ƒ To preview two design strategies
• Functional decomposition • Object Oriented design
ƒ To give a short overview of software architecture

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

2

What is Design?
ƒ Design
• The creative process of transforming a problem into a solution
• In our case, transforming a requirements specification into a detailed description of the software
ƒ Design
• The description of the solution • In our case, we will develop a software design

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

3

General Design Process

Identify nature of requirement

Requirements specification

Analyze and build model of problem

External requirements

Functional specification
Postulate a design solution

Designer’s model

Seek new solution

Functional specification
Mismatch between model and
requirements

Implement solution

Design “blueprints”

Validate solution

Designer’s

Refine design solution

Fall 2002

CSci 5801 - Dr. Mats Heimdahl model

4

Stages of Design

ƒ Problem understanding
• Look at the problem from different angles to discover the design requirements
ƒ Identify one or more solutions
• Evaluate possible solutions and choose the most appropriate depending on the designer's experience and available resources
ƒ Describe solution abstractions
• Use graphical, formal or other descriptive notations to describe the components of the design
ƒ Repeat process for each identified abstraction until the design is expressed in primitive terms

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

5

From Informal to Formal Design

Informal Design Outline
Fall 2002

Informal Design
Finished Design
CSci 5801 - Dr. Mats Heimdahl

More Formal Design
6

Sci 5801 - Dr. Mats Heimdahl

ecture 11 - Software Design Overview

Fall 200

Phases in the Design Process

Requirements Specification

Architectural Design

Abstract Specification

Design Activities

Interface Design

Component Design

Data Design

Algorithm Design

System Architecture

Software Specification

Interface Specification

Component Specification

Design Products

Data Specification

Algorithm Specification

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

7

Design Phases
ƒ Architectural design
• Identify sub-systems
ƒ Abstract specification
• Specify sub-systems
ƒ Interface design
• Describe sub-system interfaces
ƒ Component design
• Decompose subsystems into components

ƒ Data structure design
• Design data structures to hold problem data
ƒ Algorithm design
• Design algorithms for problem functions

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

8

Design Strategies

ƒ Functional design
• The system is designed from a functional viewpoint
• The system state is centralized and shared between the functions operating on that state
ƒ Object-oriented design
• The system is viewed as a collection of interacting objects
• The system state is de-centralized and each object manages its own state
• Objects may be instances of an object class and communicate by exchanging messages

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

13

Functional View of a Compiler

Source Program
Scan Source
Fall 2002

Tokens

Object Code

Build Symbol Table
Symbols
Symbol Table

Tokens
Analyze

Syntax Tree

Generate Code

Symbols

Error Indicator

Output Errors

Error Messages

CSci 5801 - Dr. Mats Heimdahl

14

Object-Oriented View of a Compiler

Source Scan Program

Token Stream

Add Check

Symbol Table
Get

Syntax Tree
Generate

Build Grammar Print Error Message

Abstract Code Generate

Object Code

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

15

Key Points
ƒ Design is a creative process ƒ Design activities include architectural
design, system specification, component design, data structure design and algorithm design ƒ Functional decomposition considers the system as a set of functional units ƒ Object-oriented decomposition considers the system as a set of objects

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

16

Sci 5801 - Dr. Mats Heimdahl

ecture 11 - Software Design Overview

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

17

Architectural Design
The High-Level Structure of a Software Intensive System

Fall 200

Architectural Parallels
ƒ Architects are the technical interface between the customer and the contractor building the system
ƒ A bad architectural design for a building cannot be rescued by good construction
• The same is true for software
ƒ There are specialist types of building and software architects
ƒ There are schools or styles of building and software architecture

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

18

Architectural Design Process
ƒ System structuring
• The system is decomposed into several principal sub-systems and communications between these sub-systems are identified
ƒ Control modeling
• A model of the control relationships between the different parts of the system is established
ƒ Modular decomposition
• The identified sub-systems are decomposed into modules

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

19

Architectural Models
ƒ Structure, control and modular decomposition may be based on a particular model or architectural style
ƒ However, most systems are heterogeneous in that different parts of the system are based on different models
ƒ The architectural model used affects the performance, robustness, distributability and maintainability of the system

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

21

System Structuring
ƒ Concerned with decomposing the system into interacting sub-systems
ƒ The architectural design is normally expressed as a block diagram presenting an overview of the system structure
ƒ More specific models showing how subsystems share data, are distributed, and interface with each other may also be developed

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

22

Sci 5801 - Dr. Mats Heimdahl

Packing Robot Control System

Vision System
Object Identification
System

Arm Controller
Packaging Selection System

Gripper Controller

Packing System

Conveyor Controller

ecture 11 - Software Design Overview

Fall 200

The Repository Model
ƒ Sub-systems must exchange data ƒ This may be done in two ways:
• Shared data is held in a central database or repository and may be accessed by all subsystems
• Each sub-system maintains its own database and passes data explicitly to other sub-systems
ƒ When large amounts of data are to be shared, the repository model of sharing is most commonly used

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

24

CASE Toolkit Architecture

Vision System

Design Editor

Code Generator

Design Translator

Project Repository

Program Editor

Design Analyzer

Report Generator

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

25

Repository Characteristics Model

ƒ Advantages
• Efficient way to share large amounts of data
• Sub-systems need not be concerned with how data is produced
• Centralized management e.g., backup, security, etc
• Sharing model is published as the repository schema

ƒ Disadvantages
• Sub-systems must agree on a repository data model
• Inevitably a compromise
• Data evolution is difficult and expensive
• No scope for specific management policies
• Difficult to distribute efficiently

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

26

Client-Server Architecture
ƒ Distributed system model which shows how data and processing is distributed across a range of components
ƒ Set of stand-alone servers which provide specific services such as printing, data management, etc
ƒ Set of clients which call on these services ƒ Network which allows clients to access
servers

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

27

Film and Picture Library

Client 1

Client 2

Client 3

Client 4

High Bandwidth Network

Catalogue Server

Video Server

Picture Server

Hypertext Server

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

28

Client-Server Characteristics

ƒ Advantages
• Distribution of data is straightforward
• Makes effective use of networked systems
• May require cheaper hardware
• Easy to add new servers or upgrade existing servers

ƒ Disadvantages
• No shared data model so sub-systems use different data organization
• Data interchange may be inefficient
• Redundant management in each server
• No central register of names and services
• It may be hard to find out what servers and services are available

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

29

Sci 5801 - Dr. Mats Heimdahl

ecture 11 - Software Design Overview

Fall 200

Abstract Machine Model
ƒ Used to model the interfacing of subsystems
ƒ Organizes 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
ƒ However, often difficult to structure systems in this way

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

30

Version Management System
Version Manager Object Manager Database System Operating System
Hardware

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

31

Control Models
ƒ Are concerned with the control flow between sub-systems
• Distinct from the system decomposition model
ƒ Centralized control
• One sub-system has overall responsibility for control and starts and stops other sub-systems
ƒ Event-based control
• Each sub-system can respond to externally generated events from other sub-systems or the system’s environment

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

32

Centralized Control
ƒ A control sub-system takes responsibility for managing the execution of other sub-systems
ƒ Call-return model
• Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards
• Applicable to sequential systems
ƒ Manager model
• Applicable to concurrent systems • One system component controls the stopping, starting
and coordination of other system processes

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

33

Call-Return Model
Main Program

Routine 1

Routine 2

Routine 3

Routine 1.1

Routine 1.2

Routine 3.1

Routine 3.2

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

34

Real-Time System Control

Sensor Processes Sensor Processes Sensor Processes Sensor Processes Sensor Processes

Actuator Processes Actuator Processes Actuator Processes Actuator Processes

System Controller

Control Processes Control Processes Control Processes Control Processes

User Interface

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

Fault Handler Fault Handler Fault Handler Fault Handler
35

Sci 5801 - Dr. Mats Heimdahl

ecture 11 - Software Design Overview

Fall 200

Event-Driven Systems
ƒ Driven by externally generated events where the timing of the event is out with the control of the sub-systems which process the event
ƒ Two principal event-driven models
• Broadcast models
• An event is broadcast to all sub-systems • Any sub-system which can handle the event may do so
• Interrupt-driven models
• Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing
ƒ Other event driven models include, for example, spreadsheets

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

36

Broadcast Model
ƒ Effective in integrating sub-systems on different computers in a network
ƒ Sub-systems register an interest in specific events
• When these occur, control is transferred to the subsystem which can handle the event
ƒ Control policy is not embedded in the event and message handler
• Sub-systems decide on events of interest to them
ƒ However, sub-systems don’t know if or when an event will be handled

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

37

Selective Broadcasting

Subsystem 1

Subsystem 1

Subsystem 1

Event and Message Handler

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

38

Interrupt-Driven Systems
ƒ Used in real-time systems where fast response to an event is essential
ƒ There are known interrupt types with a handler defined for each type
ƒ Each type is associated with a memory location and a hardware switch causes transfer to its handler
ƒ Allows fast response but complex to program and difficult to validate

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

39

Interrupt-Driven Control
Interrupts
Interrupt Vector

Handler 1 Handler 2 Handler 3 Handler 4

Process 1
Fall 2002

Process 2

Process 3

CSci 5801 - Dr. Mats Heimdahl

Process 4
40

Domain-Specific Architectures
ƒ Architectural models which are specific to some application domain
ƒ Two types of domain-specific model
• Generic models which are abstractions from a number of real systems and which encapsulate the principal characteristics of these systems
• Reference models which are more abstract, idealized model
• Provide a means of information about that class of system and of comparing different architectures

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

41

Sci 5801 - Dr. Mats Heimdahl

ecture 11 - Software Design Overview

Fall 200

Generic Models
ƒ Compiler model is a well-known example although other models exist in more specialized application domains
• Lexical analyzer • Symbol table • Syntax analyzer • Syntax tree • Semantic analyzer • Code generator
ƒ Generic compiler model may be organized according to different architectural models

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

42

Compiler Model
Symbol Table

Lexical Analysis
Fall 2002

Semantic Analysis
Syntactic Analysis
CSci 5801 - Dr. Mats Heimdahl

Code Generation
43

Language Processing System

Lexical Analysis

Syntactic Analysis

Semantic Analysis

Pretty Printer
Editor
Fall 2002

Symbol Table

Grammar Definition

Output definition

Abstract Syntax Tree

Repository

CSci 5801 - Dr. Mats Heimdahl

Optimizer
Code Generation
44

Modular Decomposition
ƒ Another structural level where sub-systems are decomposed into modules
ƒ Two modular decomposition models covered in this class
• An object model where the system is decomposed into interacting objects
• A data-flow model where the system is decomposed into functional modules which transform inputs to outputs

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

45

Key Points

ƒ The software architect is 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 and abstract machine models
ƒ Control models include centralized control and event-driven models

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

46

Key Points
ƒ Modular decomposition models include data-flow and object models
ƒ Domain specific architectural models are abstractions over an application domain
• They may be constructed by abstracting from existing systems or may be idealized reference models

Fall 2002

CSci 5801 - Dr. Mats Heimdahl

47

Sci 5801 - Dr. Mats Heimdahl
DesignModelEventControlSystems