1. Software Design CS 123/CS 231

2. 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

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

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

5. 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

6. 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

7. 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)

8. 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

9. 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

10. 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

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

12. 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)

13. 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

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

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