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

Object-Oriented Design Notation CS 123/CS 231

References zMain Reference: UML Distilled, by Martin Fowler ÕChapters 3, 4, 6, and 8 zSupplementary References: ÕChapter 14 of Sommerville ÕChapter 22 of Pressman

Component Design and Detailed Design zComponent Design ÕFor each subsystem determine components, and services/interface per component ÕOO Design: components are classes zDetailed Design ÕDetermine attributes of classes and relationships between the classes ÕDetermine functionality of each class and interactions between classes

Object-Oriented Modeling zUML: Unified Modeling Language Õ“Emerging” OO Modeling Standard ÕBooch, Jacobson, Rumbaugh zWhat is depicted? ÕClass details and static relationships ÕSystem functionality ÕObject interaction ÕState transition within an object

Some UML Modeling Techniques zClass Diagrams zUse Cases/Use Case Diagrams zInteraction Diagrams zState Diagrams

Example: Class Diagram PriceChecker getPrice() FastFood Restaurant pc counters5 FFCounter totalcash totalorders

Example: Use Case Diagram Facilitate Checkout Facilitate Return Search for Book LIBRARY SYSTEM Borrower Librarian

Example: Interaction Diagram Checkout Screen :Borrower :Book 1: checkIfDelinquent() 3: borrowBook() 2: checkIfAvailable() 4: setBorrower()

Example: State Diagram (Book) New Available Reserved Borrowed start Librarian activates book as available Borrower returns book

Object-Oriented Design Models zStatic Model ÕClass Diagrams zDynamic Model ÕUse Cases, Interaction Diagrams, State Diagrams, others

OO Static Model zClasses and Class Diagrams zRelationships ÕAssociation ÕAggregation/Composition ÕInheritance zDependencies zAttribute and Method names

OO Dynamic Model zGoal: Represent ÕObject behavior ÕObject interaction zTraditional/Procedural Dynamic Modeling ÕData Flow Diagrams (DFDs) ÕProblem: Processes separate from data ÕNeed modeling notation that highlight tight relationship between data & processes

DFD Example (Inventory Management) Accept and Post Delivery Item Master Transaction Delivery info

OO Counterpart: Object Interaction Encoder :Item Master :Transaction new (delivery info) post (item count)

Building an OO Dynamic Model zIdentify use cases zDescribe each use case through an interaction diagram zFor more complex objects, provide a state diagram per class zDerive implied methods (and attributes)

What’s Next? zNeed to understand the notation zMake sure it helps the software development process zWhen to use the UML techniques ÕPrimarily when specifying OO design ÕFormal means of communication across the different software development stages