Software Design

CS 123/CS 231

What is Design?

Design is the activity of specifying a solution to a problem

Contrast this against other software engineering phasesAnalysis: understanding and specifying

the problem (requirements)—WHAT versus HOW

Implementation: system construction

Stages in SW Design

Architectural DesignAbstract SpecificationInterface DesignComponent DesignDetailed Design

*Reference: Sommerville, Chapter 12

Architectural Design

Identify Subsystems and ModulesExample: Program Submission

SystemServerTeacher InterfaceStudent Interface

Architectural Design, continued

Design information provided is minimalSystem is simply decomposed into

interacting subsystems or modulesDepicted using a block diagram

subsystems: rectanglesarrows: represent interaction / flow of

data and control / dependency between the subsystems

Abstract Specification

Identify services and constraints per subsystem

Example: Serverset up a classset up a projectsubmit a program

Note: descriptions of services are informal

Interface Design

Per subsystem, specify its interfacecollection of available functions/methods

for use by other subsystemsConsistent with EncapsulationExample: Server

function: set_up_classparameters: catnum, section, list of

students (id#’s and names)

Interface Specification

Services per subsystem are formally specified

Goal: provide unambiguous information regarding extent of external interaction parameters/inputs, return values/outputs

Design and implementation details of the subsystem are still hidden

Component Design

Within a subsystemdetermine componentsper component, identify services/interfaces

Understand interaction between components at the level of the subsystem

OO Design: components are classesDesign models (using the UML, for

example) are most useful at this level

Detailed Design

Specify data structures and algorithms (for methods) of the individual components (classes)

Generally still implementation-independentAlthough though in practice, specific

language features are usedTechniques: Pseudocode, flowcharts,

others

Design Quality

CohesionCouplingUnderstandabilityAdaptability

*Reference: Section 12.3 of Sommerville

Cohesion

Extent of relationship between parts of a component

High cohesion is desirableSingle logical t (or “theme”)

all parts should contribute to the functionLevels of cohesion (p. 218)

coincidental cohesion (weakest)functional cohesion (strongest)

Coupling

Dependence between units of a subsystems or components

High coupling generally undesirableunits fully depend on each othersensitive to changeconvenient/necessary only for small

components

Understandability

Cohesion and Couplingunderstanding a component

independentlyNaming

reflects real-world intuitionDocumentationComplexity

algorithms

Adaptability

Sensitivity to changeare changes in design easy?

Loosely coupled componentsSelf-contained components