1. 60-322 Object-Oriented Analysis and Design Week 11, 2009

2. Mar 26, 2008 2 Ch 18. Use Case Realization for NextGen POS

3. Mar 26, 2008 3 Ch 18. Use Case Realization for NextGen POS

4. Mar 26, 2008 4 Ch 18. How to Design makeNewSale?

5. Mar 26, 2008 5 Ho w to Design enterItem?

6. Mar 26, 2008 6 Ho w to Design enterItem?

7. Mar 26, 2008 7 How to Design endSale

8. Mar 26, 2008 8 Ch 18. Use Case Realization for NextGen POS

9. Mar 26, 2008 9 How to Design getTotal()? Not all interaction diagrams start with a system operation message. They can start with any message for which the designer wishes to show interactions.

10. Mar 26, 2008 10 Ch 18. Use Case Realization for NextGen POS

11. Mar 26, 2008 11 How to Design makePayment? Remember this? bad design!

12. Mar 26, 2008 12 Logging a Sale - How to Design makePayment?

13. Mar 26, 2008 13 Logging a Sale - How to Design makePayment? Who is responsible for knowing all the logged sales and doing the logging? Store or SalesLedger?

14. Mar 26, 2008 14 Logging a Sale - How to Design makePayment? Stick with Store for now, may change to SalesLedger later during desing?

15. Mar 26, 2008 15 Calculating balance The Process Sale use case implies that the balance due from a payment be printed on a receipt and displayed somehow. Because of the Model-View Separation principle, we should not concern ourselves with how the balance will be displayed or printed. But we must ensure that it is known. No class currently knows the balance, so we need to create a design of object interactions that satisfies this requirement.

16. Mar 26, 2008 16 Calculating balance – the Reasoning To calculate the balance, we need the sale total and payment cash tendered. Therefore, Sale and Payment are partial Experts on solving this problem. If the Payment is primarily responsible for knowing the balance, it needs visibility to the Sale, to ask the Sale for its total. Since it does not currently know about the Sale, this approach would increase the overall coupling in the design - it would not support the Low Coupling pattern. In contrast, if the Sale is primarily responsible for knowing the balance, it needs visibility to the Payment, to ask it for its cash tendered. Since the Sale already has visibility to the Payment -as its creator. This approach does not increase the overall coupling and is therefore a preferable design.

17. Mar 26, 2008 17 The Final NextGen DCD for Iteration -1

18. Mar 26, 2008 18 How to Connect the UI Layer to the Domain Layer? Common designs by which objects in the UI layer obtain visibility to objects in the domain layer include the following: – An initializer object (for example, a Factory object) called from the application starting method (e.g., the Java main method) creates both a UI and a domain object and passes the domain object to the UI. – A UI object retrieves the domain object from a well- known source, such as a factory object that is responsible for creating domain objects.

19. Mar 26, 2008 19 Controller (in Coding)

20. Mar 26, 2008 20 How to Connect the UI Layer to the Domain Layer? Once the UI object has a connection to the Register instance (the facade controller in this design), it can forward system event messages, such as the enterItem and endSale message

21. Mar 26, 2008 21 Initialization and the 'Start Up' Use Case Most systems have either an implicit or explicit Start Up use case and some initial system operation related to the starting up of the application. Although abstractly, a startUp system operation is the earliest one to execute, delay the development of an interaction diagram for it until after all other system operations have been considered. This practice ensures that information has been discovered concerning the initialization activities required to support the later system operation interaction diagrams.

22. Mar 26, 2008 22 How do Applications Start Up? The startUp or initialize system operation of a Start Up use case abstractly represents the initialization phase of execution when an application is launched.  To understand how to design an interaction diagram for this operation, you must first understand the contexts in which initialization can occur. How an application starts and initializes depends on the programming language and operating system. In all cases, a common design idiom is to create an initial domain object or a set of peer initial domain objects that are the first software "domain" objects created.  This creation may happen explicitly in the starting main method or in a Factory object called from the main method.

23. Mar 26, 2008 23 How do Applications Start Up? Often, the initial domain object (assuming the singular case), once created, is responsible for the creation of its direct child domain objects. For example, a Store chosen as the initial domain object may be responsible for the creation of a Register object.

24. Mar 26, 2008 24 Choosing the Initial Domain Object Guideline Choose as an initial domain object a class at or near the root of the containment or aggregation hierarchy of domain objects. This may be a facade controller, such as Register, or some other object considered to contain all or most other objects, such as a Store. In this application, we chose the Store as the initial object.

25. Mar 26, 2008 25 Choosing the Initial Domain Object By reflecting on the prior interaction designs, we identify the following initialization work: Create a Store, Register, ProductCatalog, and ProductDescriptions. Associate the ProductCatalog with ProductDescriptions Associate Store with ProductCatalog. Associate Store with Register. Associate Register with ProductCatalog.

26. Mar 26, 2008 26 Choosing the Initial Domain Object

27. Mar 26, 2008 27 Process: Iterative and Evolutionary Object Design The essential point: Keep it light and short, move quickly to code and test, and don't try to detail everything in UML models. Model the creative, difficult parts of the design.

28. Mar 26, 2008 28 Ch 19. Designing For Visibility Visibility is the ability of one object to see or have reference to another. This chapter explores this basic but necessary design issue; those new to object design sometimes don't think about and design to achieve necessary visibility.

29. Mar 26, 2008 29 Visibility Between Objects Message are passing around among object…… For a sender object to send a message to a receiver object, the sender must be visible to the receiver - the sender must have some kind of reference or pointer to the receiver object.

30. Mar 26, 2008 30 Visibility Between Objects When creating a design of interacting objects, it is necessary to ensure that the necessary visibility is present to support message interaction

31. Mar 26, 2008 31 What is Visibility? In common usage, visibility is the ability of an object to "see" or have a reference to another object.visibility More generally, it is related to the issue of scope: Is one resource (such as an instance) within the scope of another? There are four common ways that visibility can be achieved from object A to object B:

32. Mar 26, 2008 32 What is Visibility? – Attribute visibility B is an attribute of A. – Parameter visibility B is a parameter of a method of A. – Local visibility B is a (non-parameter) local object in a method of A. – Global visibility B is in some way globally visible. The motivation to consider visibility is this: For an object A to send a message to an object B, B must be visible to A.

33. Mar 26, 2008 33 Attribute Visibility Attribute visibility from A to B exists when B is an attribute of A. It is a relatively permanent visibility because it persists as long as A and B exist. This is a very common form of visibility in object- oriented systems.

34. Mar 26, 2008 34 Parameter Visibility Parameter visibility from A to B exists when B is passed as a parameter to a method of A. It is a relatively temporary visibility because it persists only within the scope of the method. After attribute visibility, it is the second most common form of visibility in object-oriented systems.

35. Mar 26, 2008 35 Parameter Visibility It is common to transform parameter visibility into attribute visibility.

36. Mar 26, 2008 36 Local Visibility Local visibility from A to B exists when B is declared as a local object within a method of A. It is a relatively temporary visibility because it persists only within the scope of the method. After parameter visibility, it is the third most common form of visibility in object-oriented systems. Two common means by which local visibility is achieved are: – Create a new local instance and assign it to a local variable. – Assign the returning object from a method invocation to a local variable. As with parameter visibility, it is common to transform locally declared visibility into attribute visibility.

37. Mar 26, 2008 37 Local Visibility

38. Mar 26, 2008 38 Global Visibility Global visibility from A to B exists when B is global to A. It is a relatively permanent visibility because it persists as long as A and B exist. It is the least common form of visibility in object- oriented systems. One way to achieve global visibility is to assign an instance to a global variable, which is possible in some languages, such as C++, but not others, such as Java. The preferred method to achieve global visibility is to use the Singleton pattern [ch 26], which is discussed in a later chapter.

39. Mar 26, 2008 39 Ch 20 Mapping Designs to Code With the completion of interaction diagrams and DCDs for the current iteration of the case studies, there's more than enough thought and detail to cut some code for the domain layer of objects. The UML artifacts created during the design work - the interaction diagrams and DCDs - will be used as input to the code generation process. In UP terms, there exists an Implementation Model. – This is all the implementation artifacts, such as the source code, database definitions, JSP/XML/HTML pages, and so forth. Thus, the code being created in this chapter can be considered part of the UP Implementation Model.

40. Mar 26, 2008 40 Programming and Iterative, Evolutionary Development The prior design modeling should not be taken to imply that there is no prototyping or design-while- programming; modern development tools provide an excellent environment to quickly explore and refactor alternate approaches, and some (often lots) design-while-programming is worthwhile. The creation of code in an OO language - such as Java or C# - is not part of OOA/D, it's an end goal. The artifacts created in the Design Model provide some of the information necessary to generate the code.

41. Mar 26, 2008 41 Creativity and Change During Implementation Some decision-making and creative work was accomplished during design work. It will be seen during the following discussion that the generation of the code in these examples a relatively mechanical translation process. However, in general, the programming work is not a trivial code generation step - quite the opposite! Realistically, the results generated during design modeling are an incomplete first step; during programming and testing, myriad changes will be made and detailed problems will be uncovered and resolved Expect and plan for lots of change and deviation from the design during programming. That's a key and pragmatic attitude in iterative and evolutionary methods.

42. Mar 26, 2008 42 Mapping Designs to Code Implementation in an object-oriented language requires writing source code for: – class and interface definitions – method definitions The following sections discuss their generation in Java (as a typical case). The discussion is more-or-less independent of using a UML tool for code generation or working from some wall sketches.

43. Mar 26, 2008 43 Creating Classes from DCDs DCDs depict the class or interface name, superclasses, operation signatures, and attributes of a class. This is sufficient to create a basic class definition in an OO language. If the DCD was drawn in a UML tool, it can generate the basic class definition from the diagrams.

44. Mar 26, 2008 44 Creating Classes from DCDs

45. Mar 26, 2008 45 Creating Methods from Interaction Diagrams The sequence of the messages in an interaction diagram translates to a series of statements in the method definitions. The enterItem interaction diagram illustrates the Java definition of the enterItem method. For this example, we will explore the implementation of the Register and its enterItem method. A Java definition of the Register class is shown below.

46. Mar 26, 2008 46 Creating Methods from Interaction Diagrams

47. Mar 26, 2008 47 Creating Methods from Interaction Diagrams

48. Mar 26, 2008 48 Creating Methods from Interaction Diagrams

49. Mar 26, 2008 49 Collection Classes in Code

50. Mar 26, 2008 50 Exceptions and Error Handling Exception handling has been ignored so far in the development of a solution. This was intentional to focus on the basic questions of responsibility assignment and object design. However, in application development, it's wise to consider the large-scale exception handling strategies during design modeling (as they have a large-scale architectural impact), and certainly during implementation.

51. Mar 26, 2008 51 One final example (Sale.makeLineItem method)

52. Mar 26, 2008 52 Order of Implementation Classes need to be implemented (and ideally, fully unit tested) from least-coupled to most-coupled.

53. Mar 26, 2008 53 Summary As demonstrated, there is a translation process – from UML class diagrams to class definitions, and – from interaction diagrams to method bodies. There is still lots of room for creativity, evolution, and exploration during programming work. The code example for the NextGen POS case study… The main point of this listing is to show that there is a translation from design artifacts to a foundation of code. This code defines a simple case; it is not meant to illustrate a robust, fully developed Java program with synchronization, exception handling, and so on.