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

2. 2 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. Last lecture covered….

3. Feb 9, 2009 3 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. Relationship Between the Domain Layer and Domain Model

4. Feb 9, 2009 4 Relationship Between the Domain Layer and Domain Model

5. Feb 9, 2009 5 Model is a synonym for the domain layer of objects (it's an old OO term from the late 1970s).odel 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. The Model-View Separation Principle

6. Feb 9, 2009 6 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). The Model-View Separation Principle

7. Feb 9, 2009 7 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. The Model-View Separation Principle

8. Feb 9, 2009 8 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. The Connection Between SSDs, System Operations, and Layers

9. Feb 9, 2009 9 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. The messages sent from the UI layer to the domain layer will be the messages illustrated on the SSDs, such as enterItem. The Connection Between SSDs, System Operations, and Layers

10. Feb 9, 2009 10 The Connection Between SSDs, System Operations, and Layers

11. Feb 9, 2009 11 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. Ch 14 On to Object Design

12. Feb 9, 2009 12 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. Ch 14 On to Object Design

13. Feb 9, 2009 13 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. Ch 14 On to Object Design

14. Feb 9, 2009 14 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. Designing Objects: Static and Dynamic Modeling

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

16. Feb 9, 2009 16 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. Designing Objects: Static and Dynamic Modeling

17. Feb 9, 2009 17 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. Designing Objects: Static and Dynamic Modeling

18. Feb 9, 2009 18 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. Designing Objects: Static and Dynamic Modeling

19. Feb 9, 2009 19 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. Designing Objects: Static and Dynamic Modeling

20. Feb 9, 2009 20 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. Ch 14

21. Feb 9, 2009 21 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. Ch 14

22. Feb 9, 2009 22 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 Ch 14

23. Feb 9, 2009 23 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. Ch 14 Other Object Design Techniques: CRC Cards

24. Feb 9, 2009 24 Ch 14 Other Object Design Techniques: CRC Cards

25. Feb 9, 2009 25 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 Ch 15 UML Interaction Diagrams

26. Feb 9, 2009 26 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? Ch 15 UML Interaction Diagrams

27. Feb 9, 2009 27 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. Ch 15 UML Interaction Diagrams

28. Feb 9, 2009 28 Sequence diagrams illustrate interactions in a kind of fence format, in which each new object is added to the right: 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:

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

30. Feb 9, 2009 30 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). Ch 15 UML Interaction Diagrams

31. Feb 9, 2009 31 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. Sequence v. Communication Diagrams

32. Feb 9, 2009 32 – 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. Sequence v. Communication Diagrams

33. Feb 9, 2009 33 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); Sequence v. Communication Diagrams

34. Feb 9, 2009 34 Sequence v. Communication Diagrams

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

36. Feb 9, 2009 36 Example Sequence Diagrams

37. Feb 9, 2009 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. Feb 9, 2009 38 Illustrating Participants with Lifeline Boxes Common UML Interaction Diagram Notation

39. Feb 9, 2009 39 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. Basic Message Expression Syntax

40. Feb 9, 2009 40 For example: – initialize(code) – initialize – d = getProductDescription(id) – d = getProductDescription(id:ItemID) – d = getProductDescription(id:ItemID) : ProductDescription Basic Message Expression Syntax

41. Feb 9, 2009 41 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 Singleton Object :Register 1 :Store doA doX the ‘1’ implies this is a Singleton,and accessed via the Singleton pattern All these notations apply to both kinds of interaction diagrams.

42. Feb 9, 2009 42 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. Basic Sequence Diagram Notation

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

44. Feb 9, 2009 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. Feb 9, 2009 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. Feb 9, 2009 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. Feb 9, 2009 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. Feb 9, 2009 48 Diagram Frames in UML Sequence Diagram Basic Sequence Diagram Notation

49. Feb 9, 2009 49 Diagram Frames in UML Sequence Diagram Basic Sequence Diagram Notation

50. Feb 9, 2009 50 Diagram Frames in UML Sequence Diagram Basic Sequence Diagram Notation

51. Feb 9, 2009 51 Diagram Frames in UML Sequence Diagram Basic Sequence Diagram Notation