1. Object Oriented Design David Talby

2. Welcome! n Introduction n UML u Use Case Diagrams u Interaction Diagrams u Class Diagrams n Design Patterns u Composite

3. UML n Unified Modeling Language u Standard for describing designs u Visual: a set of diagrams n Unifies entire design process: u Use Cases for requirements u Static class diagrams u Object & Interaction diagrams u Components, Packages, …

4. Use Cases n A Use case is a narrative document that describes the sequence of events of an actor using a system to complete a process. n A use case diagram visualizes relationships between a system’s use cases and actors

5. Use Case Document Name: Sell Item Initiator: Customer Type: Primary, Required Actions: 1. Customer asks for X 2. Sales clerk checks if X is in stock 3. … Error Case A: if … then …

6. Use Case Diagram n Actors participate in use cases n Use cases use or extend others

7. Use Case Diagram II

8. Sequence Diagrams n A sequence diagram visualizes an ordered interaction between objects, by showing the messages sent between them. n One way to start a design is: u Translating a UC to a sequence u Turn its actions to messages

9. A Sequence Diagram

10. Sequence Diagrams II n Good time-line visualization n Supports messages to self n Supports object of same class:

11. Sequence Diagrams III n Supports conditions and loops:

12. Collaboration Diagrams n Another visual way to show the same information that a sequence diagram shows n Uses numbering of messages instead of a timeline n Both diagrams are also called interaction diagrams

13. Collaboration Diagrams

14. n Good object-centric view n Identical to Sequence diagrams u Loops, conditions, arguments u Automatic translation possible

15. Class Diagrams n Class diagrams show the static picture of the system’s classes n And relationships between them

16. Diagramming a Class n All Additions are optional u Types and argument lists u Initial values and constants

17. Dependency n Class A requires B to compile u Creates it (Instantiates) u Gets an argument

18. Association n Class A points to a B object u Can be Uni- or Bi-Directional u Each role can be named

19. Aggregation n Class A contains a list of B’s u But B’s can exist without A’s u Can be Uni- or Bi-Directional u Can be numbered

20. Composition n Class A contains a list of B’s u B’s are destroyed with their container A is destroyed u Can be Uni/Bi-Di, Numbered

21. Inheritance n Class A inherits from class B

22. Numbering n Association, Aggregation and Composition can constraint lists

23. Templates & Interfaces T n Both are supported

24. Stereotypes n Attributes of classes or methods u Standard: Interface, Abstract u Can be project-specific

25. Package Diagrams n Organize a system’s elements into related groups to minimize dependencies between them n Provides a high-level view n A UML package is analogous to u a Java package u a C++ namespace

26. Package Diagrams II

27. Package Diagrams III

28. UML Notes n Can be attached to anything T

29. Other UML Diagrams n State diagrams illustrate the states of a system or an object, and events that cause state transitions n Component diagrams show compiler and runtime dependencies between components. n Deployment diagrams show the distribution of processes and components to processing nodes. n UML is a large standard

30. Design Patterns n O-O Design is Hard n Errors are expensive n Reuse experts’ designs n Pattern = Documented experience

31. Expected Benefits n Finding the right classes n Finding them faster n Common design jargon n Consistent format n Coded infrastructures

32. O-O Programming n An interface is a contract to clients. n A class implements interface(s). n Objects are instances of classes. n Objects are only accessed through their public interfaces. n Only two relations between classes: Inheritance and composition

33. Object Relationships n Inheritance: Static and efficient, but exposes and couples modules n Composition: Hides more from client and can change dynamically n Gang of Four: “Favor composition over inheritance” n Dijkstra: “Most problems in computer science can be solved by another level of indirection”.

34. Designing for Change n The Open-Closed Principle n The Single-Choice Principle n Non-clairvoyance n Key Issue: Prepare for change! n Well, prepare for what?

35. Causes of Redesign n Dependence on hardware or software platform n Dependence on representation or implementation n Specifying a class upon creation n Algorithmic dependence n Tight coupling n Overuse of inheritance n Inability to alter classes easily

36. Pattern Categories n Creational - Replace explicit creation problems, prevent platform dependencies n Structural - Handle unchangeable classes, lower coupling and offer alternatives to inheritance n Behavioral - Hide implementation, hides algorithms, allows easy and dynamic configuration of objects

37. Pattern of Patterns n Encapsulate the varying aspect n Interfaces n Inheritance describes variants n Composition allows a dynamic choice between variants Criteria for success: Open-Closed Principle Single Choice Principle

38. 1. Composite n A program must treat simple and complex objects uniformly n For example, a painting program has simple objects (lines, circles and texts) as well as composite ones (wheel = circle + six lines).

39. The Requirements n Treat simple and complex objects uniformly in code - move, erase, rotate and set color work on all n Some composite objects are defined statically (wheels), while others dynamically (user selection) n Composite objects can be made of other composite objects n We need a smart data structure

40. The Solution n All simple objects inherit from a common interface, say Graphic: class Graphic { void move(int x, int y) = 0; void setColor(Color c) = 0; void rotate( double angle ) = 0; } n The classes Line, Circle and others inherit Graphic and add specific features (radius, length, etc.)

41. The Solution II n This new class inherits it as well: class CompositeGraphic : public Graphic, public list { void rotate(double angle) { for (int i=0; i<count(); i++) item(i)->rotate(); }

42. The Solution III n Since a CompositeGraphic is a list, it had add(), remove() and count() methods n Since it is also a Graphic, it has rotate(), move() and setColor() too n Such operations on a composite object work using a ‘forall’ loop n Works even when a composite holds other composites - results in a tree-like data structure

43. The Solution IV n Example of creating a composite: CompositeGraphic *cg; cg = new CompositeGraphic(); cg->add(new Line(0,0,100,100)); cg->add(new Circle(50,50,100)); cg->add(t); // dynamic text graphic cg->remove(2); n Can keep order of inserted items if the program needs it

44. The GoF UML n Single Inheritance n Root has add(), remove() methods

45. The Fine Print n Sometimes useful to let objects hold a pointer to their parent n A composite may cache data about its children (count is an example) n Make composites responsible for deleting their children n Beware of circles in the graph! n Any data structure to hold children will do (list, array, hashtable, etc.)

46. Known Uses n In almost all O-O systems n Document editing programs n GUI (a form is a composite widget) n Compiler parse trees (a function is composed of simpler statements or function calls, same for modules) n Financial assets can be simple (stocks, options) or a composite portfolio

47. Pattern of Patterns n Encapsulate the varying aspect n Interfaces n Inheritance describes variants n Composition allows a dynamic choice between variants Criteria for success: Open-Closed Principle Single Choice Principle