Software Design CS 123/CS 231

What is Design? zDesign is the activity of specifying a solution to a problem zContrast this against other software engineering phases ÕAnalysis: understanding and specifying the problem (requirements)— WHAT versus HOW ÕImplementation: system construction

Stages in SW Design zArchitectural Design zAbstract Specification zInterface Design zComponent Design zDetailed Design *Reference: Sommerville, Chapter 12

Architectural Design zIdentify Subsystems and Modules zExample: Program Submission System ÕServer ÕTeacher Interface ÕStudent Interface

Architectural Design, continued zDesign information provided is minimal ÕSystem is simply decomposed into interacting subsystems or modules zDepicted using a block diagram Õsubsystems: rectangles Õarrows: represent interaction / flow of data and control / dependency between the subsystems

Abstract Specification zIdentify services and constraints per subsystem zExample: Server Õset up a class Õset up a project Õsubmit a program zNote: descriptions of services are informal

Interface Design zPer subsystem, specify its interface Õcollection of available functions/methods for use by other subsystems zConsistent with Encapsulation zExample: Server Õfunction: set_up_class Õparameters: catnum, section, list of students (id#’s and names)

Interface Specification zServices per subsystem are formally specified zGoal: provide unambiguous information regarding extent of external interaction Õ parameters/inputs, return values/outputs zDesign and implementation details of the subsystem are still hidden

Component Design zWithin a subsystem Õdetermine components Õper component, identify services/interfaces zUnderstand interaction between components at the level of the subsystem zOO Design: components are classes zDesign models (using the UML, for example) are most useful at this level

Detailed Design zSpecify data structures and algorithms (for methods) of the individual components (classes) zGenerally still implementation- independent ÕAlthough though in practice, specific language features are used ÕTechniques: Pseudocode, flowcharts, others

Design Quality zCohesion zCoupling zUnderstandability zAdaptability *Reference: Section 12.3 of Sommerville

Cohesion zExtent of relationship between parts of a component zHigh cohesion is desirable zSingle logical t (or “theme”) Õall parts should contribute to the function zLevels of cohesion (p. 218) Õcoincidental cohesion (weakest) Õfunctional cohesion (strongest)

Coupling zDependence between units of a subsystems or components zHigh coupling generally undesirable Õunits fully depend on each other Õsensitive to change Õconvenient/necessary only for small components

Understandability zCohesion and Coupling Õunderstanding a component independently zNaming Õreflects real-world intuition zDocumentation zComplexity Õalgorithms

Adaptability zSensitivity to change Õare changes in design easy? zLoosely coupled components zSelf-contained components