60-322 Object-Oriented Analysis and Design

1. 60-322 Object-Oriented Analysis and Design Feb 9, 2009

2. Last lecture covered…. Logical Architecture and UML Package Diagram • The logical architecture is the large-scale organization of the software classes into packages (or namespaces), subsystems, and layers. • UML package diagrams are often used to illustrate the logical architecture of a system - the layers, subsystems, packages (in the Java sense), etc. • The responsibilities of the objects in a layer should be strongly related to each other and should not be mixed with responsibilities of other layers. • Domain Layer vs. Application Logic Layer; Domain Objects.

3. Relationship Between the Domain Layer and Domain Model The Relationship Between the Domain Layer and Domain Model?? . • We look to the domain model (which is a visualization of noteworthy domain concepts) for inspiration for the names of classes in the domain layer • The domain layer is part of the software and the domain model is part of the conceptual-perspective analysis - they aren't the same thing. • By creating a domain layer with inspiration from the domain model, we achieve a lower representational gap, between the real-world domain, and our software design.

4. Relationship Between the Domain Layer and Domain Model

5. The Model-View Separation Principle • Model is a synonym for the domain layer of objects (it's an old OO term from the late 1970s). • View is a synonym for UI objects, such as windows, Web pages, applets, and reports. • The Model-View Separation principle states that model (domain) objects should not have direct knowledge of view (UI) objects. • For example, a Register or Sale object should not directly send a message to a GUI window object ProcessSaleFrame, asking it to display something, change color, close, and so forth.

6. The Model-View Separation Principle • This principle has at least two parts: • Do not connect or couple non-UI objects directly to UI objects. • For example, don't let a Sale software object (a non-UI "domain" object) have a reference to a Java Swing JFrame window object. • Why? • Because the windows are related to a particular application, while (ideally) the non-windowing objects may be reused in new applications or attached to a new interface. • Do not put application logic (such as a tax calculation) in the UI object methods. • UI objects should only initialize UI elements, receive UI events (such as a mouse click on a button), and delegate requests for application logic on to non-UI objects (such as domain objects).

7. The Model-View Separation Principle • The domain classes encapsulate the information and behavior related to application logic. • The window classes are relatively thin; they are responsible for input and output, and catching GUI events, but do not maintain application data or directly provide application logic. • For example, a Java JFrame window should not have a method that does a tax calculation. A Web JSP page should not contain logic to calculate the tax. These UI elements should delegate to non-UI elements for such responsibilities.

8. The Connection Between SSDs, System Operations, and Layers • During analysis work, we sketched some SSDs for use case scenarios. • We identified input events from external actors into the system, calling upon system operations such as makeNewSale and enterItem. • The SSDs illustrate these system operations, but hide the specific UI objects. Nevertheless, normally it will be objects in the UI layer of the system that capture these system operation requests, usually with a rich client GUI or Web page.

9. The Connection Between SSDs, System Operations, and Layers • In a well-designed layered architecture that supports high cohesion and a separation of concerns, the UI layer objects will then forward or delegate the request from the UI layer onto the domain layer for handling. • The messages sent from the UI layer to the domain layer will be the messages illustrated on the SSDs, such as enterItem.

10. The Connection Between SSDs, System Operations, and Layers

11. Ch 14 On to Object Design • We are on our way to designing collaborating objects to fulfill project requirement. • How do you design objects? • Code • Design-while-coding (Java, C#, …). From mental model to code. • Draw, then code • Drawing some UML on a whiteboard or UML CASE tool, then switching to #1 with a text-strong IDE (e.g., Eclipse or Visual Studio). • Only draw • Somehow, the tool generates everything from diagrams. Many a dead tool vendor has washed onto the shores of this steep island. "Only draw" is a misnomer, as this still involves a text programming language attached to UML graphic elements.

12. Ch 14 On to Object Design • If we use Draw, then code (the most popular approach with UML), the drawing overhead should be worth the effort. • This chapter introduces object design and lightweight drawing before coding, suggesting ways to make it pay off.

13. Ch 14 On to Object Design How Much Time Spent Drawing UML Before Coding? Guideline • For a three-week timeboxed iteration, spend a few hours or at most one day (with partners) near the start of the iteration "at the walls" (or with a UML CASE tool) drawing UML for the hard, creative parts of the detailed object design. • Then stop - and if sketching-perhaps take digital photos, print the pictures, and transition to coding for the remainder of the iteration, using the UML drawings for inspiration as a starting point, but recognizing that the final design in code will diverge and improve. • Shorter drawing/sketching sessions may occur throughout the iteration.

14. Designing Objects: Static and Dynamic Modeling • There are two kinds of object models: dynamic and static. • Dynamic models, • Such as UML interaction diagrams (sequence diagrams or communication diagrams), help design the logic, the behavior of the code or the method bodies. • They tend to be the more interesting, difficult, important diagrams to create.

15. Designing Objects: Static and Dynamic Modeling • Static models, such as UML class diagrams, help design the definition of packages, class names, attributes, and method signatures (but not method bodies).

16. Designing Objects: Static and Dynamic Modeling • There's a relationship between static and dynamic modeling and the agile modeling practice of create models in parallel: • Spend a short period of time on interaction diagrams (dynamics), then switch to a wall of related class diagrams (statics). • People new to UML tend to think that the important diagram is the static-view class diagram, but in fact, most of the challenging, interesting, useful design work happens while drawing the UML dynamic-view interaction diagrams.

17. Designing Objects: Static and Dynamic Modeling • It's during dynamic object modeling (such as drawing sequence diagrams) that "the rubber hits the road" in terms of really thinking through the exact details of what objects need to exist and how they collaborate via messages and methods. • Therefore, we start by introducing dynamic object modeling with interaction diagrams. • Guideline: • Spend significant time doing interaction diagrams (sequence or communication diagrams), not just class diagrams. • Ignoring this guideline is a very common worst-practice with UML.

18. Designing Objects: Static and Dynamic Modeling • Note that it's especially during dynamic modeling that we apply responsibility-driven design and the GRASP principles (Ch 17 and 18). The subsequent chapters focus on these key topics of the book and key skills in OO design.

19. Designing Objects: Static and Dynamic Modeling • The most common static object modeling is with UML class diagrams. • After first covering dynamic modeling with interaction diagrams, we introduce the details. • Note, though, that if the developers are applying the agile modeling practice of Create several models in parallel, they will be drawing both interaction and class diagrams concurrently.

20. Ch 14 • The following chapters explore detailed object design while applying UML diagrams. • It's been said before, but is important to stress: • What's important is knowing how to think and design in objects, and apply object design best-practice patterns, • which is a very different and much more valuable skill than knowing UML notation.

21. Ch 14 • While drawing a UML object diagram, we need to answer key questions: • What are the responsibilities of the object? • Who does it collaborate with? • What design patterns should be applied? • Far more important than knowing the difference between UML 1.4 and 2.0 notation! • Therefore, the emphasis of the following chapters is on these principles and patterns in object design.

22. Ch 14 Object Design Skill vs. UML Notation Skill • Drawing UML is a reflection of making decisions about the design. • The object design skills are what matter, not knowing how to draw UML. Fundamental object design requires knowledge of: • principles of responsibility assignment • design patterns

23. Ch 14 Other Object Design Techniques: CRC Cards • A popular text-oriented modeling technique is Class Responsibility Collaboration (CRC) cards. • CRC cards are paper index cards on which one writes the responsibilities and collaborators of classes. • Each card represents one class. • A CRC modeling session involves a group sitting around a table, discussing and writing on the cards as they play "what if" scenarios with the objects, considering what they must do and what other objects they must collaborate with.

24. Ch 14 Other Object Design Techniques: CRC Cards

25. Ch 15 UML Interaction Diagrams Objectives • Provide a reference for frequently used UML interaction diagram notation - sequence and communication diagrams. • Note this chapter does not discuss object design, wait until Chapter 17

26. Ch 15 UML Interaction Diagrams • The UML includes interaction diagrams to illustrate how objects interact via messages. • They are used for dynamic object modeling. • There are two common types: • sequence diagrams. • communication diagrams. • This chapter introduces the notations only. • Subsequent chapters focus on a more important question: What are key principles in OO design?

27. Ch 15 UML Interaction Diagrams • Both can express similar interactions. • Sequence diagrams are the more notationally rich of the two types, but communication diagrams have their use as well, especially for wall sketching.

28. Ch 15 UML Interaction Diagrams What might this represent in code? Probably, that class A has a method named doOne and an attribute of type B. Also, that class B has methods named doTwo and doThree. Perhaps the partial definition of class A is: • Sequence diagrams illustrate interactions in a kind of fence format, in which each new object is added to the right:

29. Ch 15 UML Interaction Diagrams public class A { private B myB = new B(); public void doOne() { myB.doTwo(); myB.doThree(); } // … }

30. Ch 15 UML Interaction Diagrams • Communication diagrams illustrate object interactions in a graph or network format, in which objects can be placed anywhere on the diagram (the essence of their wall sketching advantage).

31. Sequence v. Communication Diagrams • Each diagram type has advantages, and modelers have idiosyncratic preference - there isn't an absolutely "correct" choice. • However, UML tools usually emphasize sequence diagrams, because of their greater notational power. • Sequence diagrams have some advantages over communication diagrams. • Perhaps first and foremost, the UML specification is more sequence diagram centric- more thought and effort has been put into the notation and semantics.

32. Sequence v. Communication Diagrams • It is easier to see the call-flow sequence with sequence diagrams - simply read top to bottom. • With communication diagrams we must read the sequence numbers, such as "1:" and "2:". • Hence, sequence diagrams are excellent for documentation or to easily read a reverse-engineered call-flow sequence, generated from source code with a UML tool.

33. Sequence v. Communication Diagrams • On the other hand, communication diagrams have advantages when applying "UML as sketch" to draw on walls (an Agile Modeling practice) because they are much more space-efficient. • modifying wall sketches is easier with communication diagrams - it is simple. • In contrast, new objects in a sequence diagrams must always be added to the right edge, which is limiting as it quickly consumes and exhausts right-edge space on a page (or wall);

34. Sequence v. Communication Diagrams

35. Example Sequence Diagrams public class Sale { private Payment payment; public void makePayment( Money cashTendered ) { payment = new Payment( cashTendered ); //… } // … } ` • The sequence diagram shown above is read as follows: • The message makePayment is sent to an instance of a Register. The sender is not identified. • The Register instance sends the makePayment message to a Sale instance. • The Sale instance creates an instance of a Payment

36. Example Sequence Diagrams

37. Example Communication Diagrams • Most UML novices are aware of class diagrams and usually think they are the only important diagram in OO design. Not true! • Although the static-view class diagrams are indeed useful, the dynamic-view interaction diagrams, or more precisely, acts of dynamic interaction modeling, are incredibly valuable. • Spend time doing dynamic object modeling with interaction diagrams, not just static object modeling with class diagrams

38. lifeline box representing the class Font , or more precisely , that Font is lifeline box representing a lifeline box representing an an instance of class Class – an named instance unnamed instance of class Sale instance of a metaclass «metaclass» : Sale s 1 : Sale Font List is an interface lifeline box representing an lifeline box representing instance of an ArrayList class , one instance of class Sale , in UML 1 . x we could not use an parameterized ( templatized ) to selected from the sales interface here , but in UML 2 , this ( or hold Sale objects ArrayList < Sale > collection an abstract class ) is legal sales : x : List sales [ i ] : Sale ArrayList < Sale > related example Common UML Interaction Diagram Notation Illustrating Participants with Lifeline Boxes

39. Basic Message Expression Syntax • Interaction diagrams show messages between objects; the UML has a standard syntax for these message expressions: return = message(parameter : parameterType) : returnType Parentheses are usually excluded if there are no parameters, though still legal. Type information may be excluded if obvious or unimportant.

40. Basic Message Expression Syntax • For example: • initialize(code) • initialize • d = getProductDescription(id) • d = getProductDescription(id:ItemID) • d = getProductDescription(id:ItemID) : ProductDescription

41. 1 : Register : Store the ‘ 1 ’ implies this is a Singleton , and accessed via the Singleton pattern doX doA Singleton Object • Sometimes, there is only one instance of a class instantiated, never two. • In other words, it is a "singleton" instance. • In a UML interaction diagram (sequence or communication), such an object is marked with a '1' in the upper right corner of the lifeline box All these notations apply to both kinds of interaction diagrams.

42. Basic Sequence Diagram Notation Lifeline Boxes and Lifelines • In contrast to communication diagrams, in sequence diagrams the lifeline boxes include a vertical line extending below them- these are the actual lifelines. • Although virtually all UML examples show the lifeline as dashed (because of UML 1 influence), in fact the UML 2 specification says it may be solid or dashed.

43. Messages, Focus Control and Execution Spec. Bar Basic Sequence Diagram Notation

44. Illustrating Reply or Returns Basic Sequence Diagram Notation • There are two ways to show the return result from a message: • Using the message syntax returnVar = message(parameter). • Using a reply (or return) message line at the end of an execution spec. bar.

45. Message to “self” or “this” Basic Sequence Diagram Notation • You can show a message being sent from an object to itself by using a nested Exec. Spec. bar

46. Creation of Instance Basic Sequence Diagram Notation • The typical interpretation (in languages such as Java or C#) of a create message on a dashed line with a filled arrow is "invoke the new operator and call the constructor".

47. Diagram Frames in UML Sequence Diagram Basic Sequence Diagram Notation • To support conditional and looping constructs (among many other things), the UML uses frames. • Frames are regions or fragments of the diagrams; they have an operator or label (such as loop) and a guard(conditional clause).

48. Diagram Frames in UML Sequence Diagram Basic Sequence Diagram Notation

49. Diagram Frames in UML Sequence Diagram Basic Sequence Diagram Notation

50. Diagram Frames in UML Sequence Diagram Basic Sequence Diagram Notation