Lecture 8

Component-Level Design

Component-Level Design the closest design activity to coding the approach:

review the design description for the component

use stepwise refinement to develop algorithm

use structured programming to implement procedural logic

use ‘formal methods’ to prove logic

Stepwise Refinement

openopen

walk to door;walk to door;reach for knob;reach for knob;

open door;open door;

walk through;walk through;close door.close door.

repeat until door opensrepeat until door opensturn knob clockwise;turn knob clockwise;if knob doesn't turn, thenif knob doesn't turn, then take key out;take key out; find correct key;find correct key; insert in lock;insert in lock;endifendifpull/push doorpull/push doormove out of way;move out of way;end repeatend repeat

The Component-Level Design Model

represents the algorithm at a level of detail that can be reviewed for quality

options: graphical (e.g. flowchart, box diagram) pseudocode (e.g., PDL) programming language decision table

conduct walkthrough to assess quality

Structured Programming

uses a limited set of logical constructs: sequence conditional — if-then-else, select-case loops — do-while, repeat until

leads to more readable, testable code

important for achieving high quality, but not enough

A Structured Procedural Design

a

x1

x2b

3x

4

5

c

d

ef

g

x

x

add a condition Z, if true, exit the program

Program Design Language

if-then-else

if condition x then process a; else process b; endif

PDL

easy to combine with source code machine readable, no need for graphics input graphics can be generated from PDL enables declaration of data as well as procedure easier to maintain

Why Design Language?

can be a derivative of the HOL of choice e.g., Ada PDL machine readable and processable can be embedded with source code, therefore easier to maintain can be represented in great detail, if designer and coder are different easy to review

Object-Oriented Design

OOA and OOD

Object-relationship

model

Object-BehaviorModel

CRCIndex Cards

Attributes, operations,collaborators

THE ANALYSIS MODEL

responsibilitiesdesign

messagedesign

Class and objectdesign

subsystemdesign

THE DESIGN MODEL

Use cases

OOA and OOD

classesclassesattributesattributesmethodsmethodsrelationshipsrelationshipsbehaviorbehavior

Analysis ModelAnalysis Model

objectsobjectsdata structuresdata structuresalgorithmsalgorithmsmessagingmessagingcontrolcontrol

Design ModelDesign Model

OOD Representation of hierarchy of modules Specification of data definitions Specification of procedure logic Indication of end-to-end processing sequences Representation of object states and transitions Definition of classes and hierarchies Assignment of operations to classes Detailed definition of operations Specification of message connections Identification of exclusive services

Design Issues decomposability—the facility with which a design method helps the

designer to decompose a large problem into sub-problems that are easier to solve;

composability—the degree to which a design method ensures that program components (modules), once designed and built, can be reused to create other systems;

understandability—the ease with which a program component can be understood without reference to other information or other modules;

continuity—the ability to make small changes in a program and have these changes manifest themselves with corresponding changes in just one or a very few modules;

protection—a architectural characteristic that will reduce the propagation of side affects if an error does occur in a given module.

Generic Components for OOD Problem domain component—the subsystems that

are responsible for implementing customer requirements directly;

Human interaction component —the subsystems that implement the user interface (this included reusable GUI subsystems);

Task Management Component—the subsystems that are responsible for controlling and coordinating concurrent tasks that may be packaged within a subsystem or among different subsystems;

Data management component—the subsystem that is responsible for the storage and retrieval of objects.

Process Flow for OOD

System design

object design

task management design

data management designhuman

interface design

Object-oriented analysis

System Design Process• Partition the analysis model into subsystems.• Identify concurrency that is dictated by the problem.• Allocate subsystems to processors and tasks.• Develop a design for the user interface.• Choose a basic strategy for implementing data

management.• Identify global resources and the control mechanisms

required to access them.• Design an appropriate control mechanism for the system,

including task management.• Consider how boundary conditions should be handled.• Review and consider trade-offs.

System Design

requestclientsubsystem

contract

contract contract

request

request

serversubsystem

peersubsystem

peersubsystem

Subsystem Example

assign to zonetest status

request for alarm notificationperiodic check-in

require for configuration update

request for statusControlpanel

subsystem

Sensorsubsystem

Centralcommunication

subsystem

request for system statusspecification of type of alarm

periodic status check

Subsystem Design Criteria The subsystem should have a well-defined

interface through which all communication with the rest of the system occurs.

With the exception of a small number of “communication classes,” the classes within a subsystem should collaborate only with other classes within the subsystem.

The number of subsystems should be kept small.

A subsystem can be partitioned internally to help reduce complexity.

Subsystem Collaboration Table

Contract

Type

Collaborators

Class(es)

operation(s)

Message Format

Object Design A protocol description establishes the

interface of an object by defining each message that the object can receive and the related operation that the object performs

An implementation description shows implementation details for each operation implied by a message that is passed to an object. information about the object's private part internal details about the data structures that

describe the object’s attributes procedural details that describe operations

Design Patterns

... you’ll find recurring patterns of classes and communicating objects in many object-oriented systems. These patterns solve specific design problems and make object-oriented design more flexible, elegant, and ultimately reusable. They help designers reuse successful designs by basing new designs on prior experience. A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them.

Gamma and his colleagues [GAM95]

Design Pattern Attributes The design pattern name is an abstraction that

conveys significant meaning about it applicability and intent.

The problem description indicates the environment and conditions that must exist to make the design pattern applicable.

The pattern characteristics indicate the attributes of the design that may be adjusted to enable the pattern to accommodate into a variety of problems.

The consequences associated with the use of a design pattern provide an indication of the ramifications of design decisions.

OOD DocumentationOOA

Use case / use case diagramObject diagram (ERD)Class diagramCRC Collaboration diagram State diagramor Event trace Event flow

OODUse case / use case diagramObject diagram (ERD)Class diagram (including packages)CRCGUI designCollaboration diagramSequence diagramState diagramActivity diagram

Interaction Diagrams are used to describe how operations and behaviors are handled by the objects in the design.

There are two types of interaction diagrams: sequence and collaboration diagram

Sequence diagram shows the sequence in which activities or behaviors occur (represented by a time line)

Collaboration diagram shows how the objects are connected statically. Sequence of actions are numbered

A state diagram shows the possible states an object can take, the events that trigger the transition from one state to the next, and the actions that result from each state change

An activity diagram models the flow of procedures or activities in a class