CMSC 345 Fall 2000

Design

What is Design? Verb: The creative process of

transforming the problem into the solution

Noun: The description of the solution Typically multiple acceptable soultions Two types of design

Conceptual for the customer Technical for the developer

Conceptual Design Tells the customer what the system

will do Characteristics of Conceptual

Design Written in customer language No technical jargon Describes functions of the system Independent of the implementation Links to requirements documents

Conceptual Design (2) System defined by its boundaries,

entities, attributes and relationships Answer questions:

Where will the data come from? What will happen to the data in the system? What will the system look like to users? What choices will be offered to users? What is the timing of events? What will the reports and screens look like?

Technical Design More detailed than conceptual design Describes the form the system will take Description of major hardware

components and their interactions (if not part of problem space)

Hierarchy and function of software components (those not part of problem)

Major data structures used within system and data flow through system

WHAT HOW

Customers Systembuilders

CONCEPTUALDESIGN

TECHNICALDESIGN

function formSystemdesigners

CONCEPTUALDESIGN

TECHNICALDESIGN

“The user will be able to route messages to any other user on any other network computer.”

Network topologyProtocol usedPrescribed bps rate. . .

Decomposition and Modularity To design a system is to determine

a set of components and interfaces that satisfy the requirements.

Many ways to create good design, but….

Every design method involves some kind of decomposition

Design Strategies Functional design

system is designed from a functional viewpoint and progressively refined

The system state is centralized and shared between the functions operating on that state

Object-oriented design system is viewed as a collection of objects.

Based on the idea of information hiding 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 methods

Design Stages (Sommerville) Architectural design Identify sub-systems Abstract specification Specify sub-systems Interface design Describe sub-system

interfaces Component design Decompose sub-systems

into components Data structure design Design data structures

to hold problem data Algorithm design Design algorithms for

problem functions

Design Methods (Wasserman) Modular decomposition: assign functions to

components Data-oriented decomposition: based on

external data structures. Event-oriented decomposition: based on

how events handled by system change the system state

Outside-in: black-box approached based on user inputs to the system

Object-Oriented : identifies classes of objects and their relationships

Toplevel

First level ofdecomposition

Second level ofdecomposition

Architectural Design Architecture: associates system

capabilities with components that will implement them, and their interconnections

Code: involves algorithms and data structures, primitives and compositions in terms of language primitives

Executable: memory allocation, data formats, bit patterns, etc.

Architectural Styles Pipes and Filters Object-Oriented Implicit Invocation Layering Repositories Process Control Others…

Pipes and Filter Architecture aka Data-Flow model Pipes are streams of data for input

and output Filters transform the input to

output Filters are independent and

“unaware” of other filters

FilterPipe

Invoice processing system

Read issuedinvoices

Identifypayments

Issuereceipts

Findpayments

due

Receipts

Issuepaymentreminder

Reminders

Invoices Payments

Pipe and Filter Plus and Minus Plus – Filters easily reused Plus – Easy to add/remove filters Plus – Easy to implement as concurrent

or sequential system Minus – Not good for interactive systems Minus – Independent filters may duplicate

(preparatory) processing Minus – Must maintain correspondence

between multiple data streams

Object Oriented Architecture Each component is an instance of an ADT.

Components must preserve integrity of data representation, keeping hidden from other objects

Decompose problem into system loosely coupled objects with well defined interfaces

However, each object must know identity of other objects it interacts with, and all objects that invoke a changed object must themselves be changed

Invoice processing system

IssueSend reminderAccept paymentSend receipt

invoice #dateamountcustomer

Invoice

customer #nameaddresscredit period

Customer

invoice #dateamountcustomer #

Receipt

invoice #dateamountcustomer #

Payment

OO Plus and Minus Plus – loosely coupled objects allow

changing implementation without affecting other objects

Plus – objects represent “real world” entities and are therefore reusable

Minus – objects must explicitly reference name and interface of other objects, so interface change affects all other objects

Minus – complex objects may be difficult to represent

Layering Architecture Models the interfacing of

subsystems Layers are hierarchical Each layer provides a service to the

one outside of it and is a client to the layer inside of it

Each layer is an increased level of abstraction

Users

Cryptography

File interface

Key management

Authentication

Layering Plus and Minus Plus – portable and changeable if the

interface between layers is preserved Plus – machine dependencies localized

in the inner layers Minus – structuring the system in this

way may be difficult Minus – multiple layers require multiple

levels of command interpretation which may affect performance

Client-Server Architecture Distributed system architecture Client requests action or service Server responds to the request Clients must know the name of the

available servers and the services they provide

Servers need not know the identity of clients or how many there are

Clients access services provide by a server through a remote procedure call

Film and picture library

Catalogueserver

Catalogue

Videoserver

Film clipfiles

Pictureserver

Digitizedphotographs

Hypertextserver

Hypertextweb

Client 1 Client 2 Client 3 Client 4

Wide-bandwidth network

Client-Server Plus and Minus Plus – clients get information only

when they need it. Plus – distribution is straightforward Plus – clients handle presentation

details Minus – require sophisticated

security, systems management, more resources to implement and support

Characteristics of OOD Objects are abstractions of real-world or

system entities and manage themselves Objects are independent and encapsulate

state and representation information. System functionality is expressed in terms of

object services Shared data areas are eliminated. Objects

communicate by message passing Objects may be distributed and may execute

sequentially or in parallel

OOD Structure

state 3

O3

state 4

O4

state 1

O1

state 6

O6

state 5

O5

state 2

O2

Advantages of OOD Easier maintenance. Objects may be

understood as stand-alone entities Objects are appropriate reusable

components For some systems, there may be an

obvious mapping from real world entities to system objects

OOD Method Commonality The identification of objects, their

attributes and services The organization of objects into an

aggregation hierarchy The construction of dynamic object-

use descriptions which show how services are used

The specification of object interfaces

Objects, Classes and Inheritance Objects are entities in a software

system which represent instances of real-world and system entities

Object classes are templates for objects. They may be used to create objects.

Object classes may inherit attributes and services from other object classes

A Mail_Message Object Class

SenderReceiver

Sender addressReceiver address

Date sentDate received

RouteTitleText

SendPresentFile

Print

Mail message

ObjectsAn object is an entity which has a state and a defined set of

operations which operate on that state. The state is represented as a set of object attributes. The operations associated with the object provide services to other objects (clients) which request these services when some computation is required. Objects are created according to some object class definition. An object class definition serves as a template for objects. It includes declarations of all the attributes and services which should be associated with an object of that class.

Object Communication Conceptually, objects communicate by

message passing. The name of the service requested by the calling

object. Copies of the information required to execute the

service and the name of a holder for the result of the service.

In practice, messages are often implemented by procedure calls Name = procedure name. Information = parameter list.

Inheritance Objects are members of classes which define

attribute types and operations Classes may be arranged in a class hierarchy

where one class is derived from an existing class (super-class)

A sub-class inherits the attributes and operations from its super class and may add new methods or attributes of its own

A Class Hierarchy

Employee

NameAddressSalar yManager. . .

Programmer

ProjectProg languages

Manager

DeptStaffGrade. . .

Projectmanager

ProjectDate Appointed. . .

Advantages of Inheritance It is an abstraction mechanism which

may be used to classify entities It is a reuse mechanism at both the

design and the programming level The inheritance graph is a source of

organizational knowledge about domains and systems

Problems with Inheritance Object classes are not self-contained. they

cannot be understood without reference to their super-classes

Designers have a tendency to reuse the inheritance graph created during analysis. Can lead to significant inefficiency

The inheritance graphs of analysis, design and implementation have different functions and should be separately maintained

Object Identification Identifying objects is the most difficult part

of object oriented design.

There is no 'magic formula' for object identification. It relies on the skill, experience and domain knowledge of system designers.

Object identification is an iterative process. You are unlikely to get it right first time

Approaches to Identification Use a grammatical approach based on a

natural language description of the system

Base the identification on tangible things in the application domain

Use a behavioral approach and identify objects based on what participates in what behavior

Use a scenario-based analysis,

Objects and Operations Nouns in the description give pointers to

objects in the system Verbs give pointers to operations

associated with objects Approach assumes that the designer

has a common sense knowledge of the application domain as not all objects and services are likely to be mentioned in the description

Static System Structure Object aggregation hierarchy

diagrams show the static system structure. They illustrate objects and sub-objects. This is NOT the same as an inheritance hierarchy

Aggregation Hierarchy

BarometerAir

thermometerGround

ther mometer Rain gauge Wind vane Anemometer

Weatherdata Instr uments Clock Comms

Met.data

Weather *station

Mapdatabase

Weathermap

Weathermappingsystem

. . . . . . . . .

. . .. . .

Dynamic System Structure Object-service usage diagrams

illustrate how objects use other objects. They show the messages passed (procedures called) between objects

Object Interactions

RainfallGround temp .

dataAir temp.

dataWind direction

data PressureWind speed

data

Cumulative Readings Average AverageMax. gust

MaximumMinimumAverage

Weatherdata

Processdata

Weatherstation

Transmitdata

Transmitdata

Comms Comms

Object Interface Design Concerned with specifying the detail of

the object interfaces. This means defining attribute types and the signatures and semantics of object operations

Representation information should be avoided

Precise specification is essential so a programming language description should be used

C++ Interfaceclass Weather_station {public: Weather_station () ; ~Weather_station () ; void Transmit_data (computer_id dest) ; void Transmit_status (computer_id dest) ; void Self_test () ; void Shut_down () ;

// Access and constructor functionschar* Identifier () ;void Put_identifier (char* Id) ;instrument_status Inst_status () ;void Put_instrument_status (Instrument_status ISD) ;weather_data_rec Weather_data () ;void Put_weather_data (weather_data_rec WDR) ;

private: char* station_identifier ; weather_data_rec Weather_data ; instrument_status inst_status ;} ;

Concurrent Objects The nature of objects as self-contained

entities make them suitable for concurrent implementation

The message-passing model of object communication can be implemented directly if objects are running on separate processors in a distributed system

OO Key Points OOD is design with information hiding.

Representations may be changed without extensive system modifications

An object has a private state with associated constructor and access operations. Objects provide services (operations) to other objects.

Object identification is a difficult process. Identifying nouns and verbs in a natural language description can be a useful starting point for object identification.

OO Key Points Object interfaces must be precisely

defined. A programming language such as Ada or C++ may be used for this

Useful documentation of an OOD include object hierarchy charts and object interaction diagrams