1 Software Design Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13, 5 th edition...

1

Software Design

Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13, 5th edition and Ch. 10, 6th edition

2

Topics• What is Design?• Design Description • The Design Process

– Architectural Design

• Design Strategies– Functional– OO

• Design Quality– Component Cohesion– Component Coupling

3

What is Design?

• Where informal ideas are transformed to detailed implementation descriptions

• It is a creative process

• There is no design “cookbook”

• It is learned by experience and study of existing systems

4

Design DescriptionThree main design notations:

• Graphical notations– Display relationships between components– Relate the design to the real-world system

• Program Description Languages (PDLs)– Pseudocode

• Informal text– For anything that can’t be described formally

(e.g., design rationale, non-functional considerations)

5

The Design Process

• Architectural Design– Subsystems and their relationships are

identified and documented

• Abstract Specification– Document an abstract specification of the

services provided by and constraints on each subsystem

• Interface Design– Document each subsystem’s interface

6

The Design Process (con’t)

• Component Design– Break subsystems into components and

document their interfaces

• Data Structure Design– Specify the data structures used in the

system implementation

• Algorithm Design– Specify the implementation algorithms

7

Architectural DesignHow a system is decomposed into subsystems

that provide some related set of services• Different “flavors” of architectural design

models:– Structural models– Control models– Others

• There is no one “correct” architectural design model.

• Designs may be hybrids of several models or even self-defined.

8

Structural Model Examples

• Simple block diagram

• Domain-independent architectures– Repository Model– Client-Server Model– Event-driven Model– Many others ...

• Domain-specific architectures

9

Simple Block Diagram

• Presents an overview of the system structure (subsystems) and their interconnections

• Good overview, but may not present enough information (e.g., connection to databases)

10

Alarmcontroller

Voicesynthesizer

Movementsensors

Siren

Doorsensors

Telephonecaller

Externalcontrol centre

Intruder Alarm System

11

Visionsystem

Objectidentification

system

Armcontroller

Grippercontroller

Packagingselectionsystem

Packingsystem

Conveyorcontroller

A Packing Robot Control System

12

Repository Model

• Systems which use large amounts of data are organized around a shared database or repository

• Suited to applications where data is generated by one subsystem and used by others

• Example: a management information system

13

Student Information Repository

CourseScheduleGenerator

TranscriptGenerator

GraduationCheckoutSystem

StudentRegistration

System

Grade ReportGenerator

A Student Information System

14

Projectrepository

Designtranslator

Programeditor

Designeditor

Codegenerator

Designanalyser

Reportgenerator

A CASE Toolset

15

Client-Server Model

• A distributed system model which shows how data and processing is distributed across a range of processors

• Servers offer services to other subsystems

• Clients call on the services offered by the servers

16

Film and picture library

Catalogueserver

Catalogue

Videoserver

Film clipfiles

Pictureserver

Digitizedphotographs

Hypertextserver

Hypertextweb

Client 1 Client 2 Client 3 Client 4

Wide-bandwidth network

17

Control Models

Are concerned with the control flow between subsystems.

Examples:– Centralized control: One subsystem has

overall responsibility for control and starts and stops other subsystems

– Event-driven: System is driven by externally generated events where the timing of the event is out of the control of the subsystem(s) that processes the event (e.g., spreadsheets, GUIs)

18

Design Strategies

• Functional DesignSystem is designed from a functional

viewpoint, starting with a high-level view and refining this into a more detailed design. The system state is centralized and shared between the functions.

• Object-oriented DesignSystem is viewed as a collection of objects

rather than functions. The system state is decentralized. Each object manages its own information.

19

Design Quality

What is “good” design? No general agreement, but ...

• Should correctly implement specification• Must be understandable

– Good naming conventions– Good internal and external documentation– Minimize complex algorithms

• Must be able to adapt to modification or addition of new functionality– High component cohesion– Low component coupling

20

Component Cohesion

• A measure of the closeness of the relationships between the component’s components

• Component should implement a single logical function/task (functional) or implement a single logical entity (OO)

• We want strong cohesion

21

Component Cohesion (con’t)7 levels of cohesion (Constantine &

Yourdan), weakest to strongest:• Coincidental Cohesion

– The parts of a component are not related but simply bundled into a single component

• Logical Association– Components that perform similar functions

such as input, error handling and so on are put together in a single component

22

Component Cohesion (con’t)• Temporal Association

– All of the components that are activated at a single time, such as start up or shut down, are brought together

• Procedural Cohesion– The elements in a component make up a

single control sequence

• Communicational Cohesion– All of the elements of a component operate

on the same input data or produce the same output data

23

Component Cohesion (con’t)

• Sequential Cohesion– The output from one element in the component

serves as input for some other element

• Functional Cohesion– Each part of the component is necessary for

the execution of a single function/task

24

Component Cohesion (con’t)Cohesion applies to both functional and

OO design approaches:

• Cohesive Function– Performs a single task

• Cohesive Object– A single entity is represented and all the

operations on that entity are included with the object

So, which promotes strong cohesion better -- functional or OO design?

25

Component Coupling

• A measure of the strength of the interconnections between components in a design

• Want components to be as independent as possible

• We want low coupling

26

Component Coupling (con’t)

• Functional Design– No/little global data– No hard-coded constants– Nothing that causes one function to require

knowledge of another’s implementation

• OO Design– Inheritance by nature causes coupling between

base and derived classes– Multiple inheritance greatly increases coupling

27

How Components Are Coupled• References from one component to another, such as invocation

• Amount of data passed from one component to another

• Amount of control one component has over another

• Degree of complexity of interface, e.g., one entry point vs. mutual entry points

28

Goal is to Minimize Coupling• Enables us to change portion of system while disrupting rest of system little as possible

• Very low coupling might allow pull-out, plug-in replacement of only one component

• Loose coupling may require changing or replacing a few components

• High coupling may require widespread perturbations in system

• Low coupling reduces the number of components needing revision

29

Types of Coupling

• Content: one component directly modifies data or control flow of another

• Common: Organizing data into a common store

• Control: Control flags passed as parameters between components

• Stamp: Data structures passed• Data: Only primitive data passed