Object-oriented designGoals of OO analysis (quick review)Goals of OO designFour activities of design (Coad)How does this design illustrate the separation of concerns principle?Four activities of design (continued)Reworking the class diagramReworking the class diagram (continued)Classes as active state machinesClasses as active state machines (cont.)Key idea for OOD: data structures can be activeCase Study: Full‑Screen Entry SystemsState diagrams in UMLSuper-statesUML package diagramsDesign process proceduresObject-oriented designCSE 432: Object-Oriented Software EngineeringGoals of OO analysis (quick review)What are the two main goals of OO analysis?1) Understand the customer’s requirements2) Describe problem domain as a set of classes and relationshipsWhat techniques have we studied for the 1st goal?Develop a requirements specificationDescribe scenarios of use in user’s language as use casesWhat techniques have we studied for the 2nd goal?CRC cards discover classes and run simulationsUML class diagrams represent classes & relationshipsSequence diagrams model dynamic behavior of a systemGoals of OO designOO design develops the analysis into a blueprint of a solutionWhere does the “blueprint” metaphor come from?OO design starts by fleshing the class diagramsCoad & Nicola call this "the continuum of representation principle: use a single underlying representation, from problem domain to OOA to OOD to OOP," i.e., class diagrams Reworks and adds detail to class diagrams, e.g., attribute types, visibility (public/private), additional constraints Looks for opportunities for reuse Addresses performance issues, both for system and usersDesigns UI, database, networking, as neededDesigns ADT to describe the semantics of classes in more detail Develops unit test plans based on class diagrams and ADT designFour activities of design (Coad)1) Improve domain analysis: reuse and performance OOA focuses primarily on the describing problem domain itselfOOD reexamines the domain with an eye to practical concerns Reuse: factor out common code in abstract classesPerformance tradeoffs: efficiency vs. effectiveness2) Human interaction: encapsulates user interfaceHIC knows how to present data, not how to compute itSeparation of concerns principle: Keep problem domain classes distinct from human interaction classes. Why?Loose coupling facilitates software reuse and maintenanceAn example: the Smalltalk Model-View-Controller framework: model is the problem domainview is the human interface (windows that view the problem domain objects)controller is the mouse or keyboard input, also interacting with P.D. objectsC++ Interviews is two part framework: subject (problem domain) & views (UI)How does this design illustratethe separation of concerns principle?Four activities of design (continued)3) Task managementMulti‑tasking and concurrency considerationsHow does separation of concerns apply here?Examples?4) Data managementStorage and retrieval of external dataDatabase design (relational or object-oriented)Or database interface (JDBC, CORBA)How does separation of concerns apply here?Reworking the class diagramAdd new relations implied in classesInverse operations (e.g., undo/redo, getData/setData)Factor complex behaviors out as classes themselvesIf only difference between subclasses is presentation of data, use a serviceShould we derive HexCount, BinaryCount, OctCount from Count?Rather, add a service, asBase, to present data in different basesDistinguish client (has-a) and inheritance (is-a) relationsMisuse of multiple inheritance is when a derived class is "composed of" several parent classesI.e., class AIRPLANE has parents WINGS, ENGINE, TAIL) But the behavior of AIRPLANE is not just the sum of its partsBjarne Stroustrup's heuristic: "can it have two?" Then it's a containment, or has-a relationReworking the class diagram (continued)Heuristic: use inheritance to extend existing classesE.g., ComplexMatrix adapts Array or OrderedCltnBut avoid adapting parents for the sake of their heirs (open‑closed principle)Generalize common behaviors in abstract classesE.g., Mouse, Tablet and Keyboard can all inherit behavior from an abstract class, InputDevice Use multiple inheritance for compound classesTeachingAssistant inherits from both Instructor and StudentWindow as a compound of Rectangle (graphical behaviors) and Tree (hierarchical behaviors)Note: many OO languages don’t support multiple inh.Classes as active state machinesConsider whether a class should keep track of its own internal stateExample from Bertrand Meyer: first cut design of LINKED_LIST classclass LINKABLE[T] ‑‑linkable cells feature value:T; right: LINKABLE[T]; ‑‑next cell ‑‑routines to change_value, change_right end; class LINKEDLIST[T] feature nb_elements: INTEGER; first_element: LINKABLE[T]; value(i:INTEGER):T is ‑‑value of i‑th element; loop until it reaches the ith element insert(i:INTEGER; val:T); ‑‑loop until it reaches ith element, then insert val delete(i:INTEGER); ‑‑loop until it reaches ith element, then delete itProblems with first‑cut?Getting the loops right is tricky (loops are error‑prone)Redundancy: the same loop logic recurs in all these routinesReuse leads to inefficiency: suppose I want a routine searchFind an element then replace it: I'll do the loop twice!Need some way to keep track of the position I found!Could return the LINKABLE cell found, but this would ruin encapsulationClasses as active state machines (cont.)Instead, view LINKED_LIST as a machine with an internal stateInternal state is information stored as attributes of an objectWhat have we added to represent internal state?Cursor: current position in the listsearch(item) routine moves the cursor until it finds iteminsert and delete operate on the element pointed at by cursorHow does this simplify the code of insert, delete, etc.?Client has a new view of LINKED_LIST objects: l.search(item); ‑‑find item in l if not offright then delete end; ‑‑delete LINKABLE at cursorOther routines move cursor: l.back; l.forthKey idea for OOD: data structures can be activeActive structures have internal states, which changeRoutines manipulate the