Object-oriented design

1. Object-oriented design CSE 432: Object-Oriented Software Engineering

2. Goals of OO analysis (quick review) • What are the two main goals of OO analysis? 1) Understand the customer’s requirements 2) 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 system

3. Goals 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 "thecontinuum 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 design

4. Four 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 problemdomain classesdistinct 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)

5. How does this design illustratethe separation of concerns principle?

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

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

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

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

10. Classes as active state machines (cont.) • Instead, view LINKED_LIST as a machine with an internalstate • 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.forth

11. Key idea for OOD: data structures can be active • Active structures have internal states, which change • Routines manipulate the object's state • What other classes could be designed this way? • Files, random number generators, tokenizers, ... • Class as state machine view may not be obvious during analysis • A good reason for redesign!

12. Case Study: Full‑Screen Entry Systems • Straightforward data processing application: menu‑driven data entry (see overhead) • Each menu comes with a panel of information & lets user choose next action • Interaction during a airline reservation session • Enquiry on flights, information & possible new states • Meyer shows different ways to solve problem • goto flow (50's), • functional decomposition (70's) • OO design (90's): improves reusability and extensibility

13. State diagrams in UML • States in ovals, transitions as arrows • Transitions labels have three optional parts: Event [Guard] / Action • Item Received is an event, /get first item is an action, [Not all items checked] is a guard • State may also label activities, e.g., do/check item • Actions, associated with transitions, occur quickly and aren’t interruptible • Activities, associated with states, can take longer and are interruptible • Definition of “quickly” depends on the kind of system, e.g., real-time vs. info system

14. Super-states • Example shows a super-state of three states • Can draw a single transition to and from a super-state • How does this notation make things a bit clearer? • Concurrency in state diagrams • Dashed line indicates that an order is in two different states, e.g. Checking & Authorizing • When order leaves concurrent states, it’s in a single state: Canceled, Delivered or Rejected • When should you create UML state diagrams?

15. UML package diagrams • UML packages for higher level structure (Coad’s subjects) • Denoted by box with smaller box on top • Note dependency arrows • A dependency indicates that changes to one element may cause changes to the other • Packages can be grouped in higher-order packages • Packages may include packages • Common package as <<global>> means all packages in system have dependency to this one • General package marked {abstract} means this package is an interface, with subtypes • Heuristic: divide classes into packages; analyze dependencies; refactor to reduce dependencies

16. Design process procedures • Conduct peer reviews at every stage of process • CRC cards: run simulations to discover missing responsibilities • Conduct peer review of class diagrams: does it cover the domain? • Explain design, looking for opportunities for iterative redesign • Contract design: peer review ADTs or assertions • Test design: review plans for unit and acceptance testing • Plan testing on a per class basis • Write system and unit test plan descriptions as part of class design • Unit test all public member functions • Test for valid, invalid and boundary cases • System testing follows thorough class testing • See Junit tool for automated test generation support