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

16. Object-Oriented Design Notation CS 123/CS 231

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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