1. © 2005 Prentice Hall8-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.

2. © 2005 Prentice Hall8-2 Learning Objectives Explain fundamental object-oriented concepts. Understand what patterns are and how they are used. Learn how to assign responsibilities to classes using the Façade, Creator, and Expert patterns.

3. © 2005 Prentice Hall8-3 Learning Objectives (continued) Understand the differences between collaboration and sequence diagrams. Create interaction diagrams.

4. © 2005 Prentice Hall8-4 Overview The models used in object-oriented program design represent interacting units of software, known as objects. These objects communicate with each other by messages to carry out the required responses of the system.

5. © 2005 Prentice Hall8-5 Overview (continued) The chief task of object-oriented program design is to assign responsibilities to the objects. This assignment of responsibilities is guided by patterns – design solutions based on the experience of software design professionals.

6. © 2005 Prentice Hall8-6 Overview (continued) Object-oriented program design is a seven-step process. Chapter 8 presents the first step – producing an interaction diagram for each system operation identified during analysis.

7. © 2005 Prentice Hall8-7 Overview (continued) The interaction diagrams are developed on the basis of system operation contracts produced during analysis. This overall approach is called “design by contract.”

8. © 2005 Prentice Hall8-8 Overview (continued) As discussed in Chapter 5, design by contract assumes a commitment to a contract on the part of the object which receives a message. The preconditions and postconditions of the system operation contracts drive the program design.

9. © 2005 Prentice Hall8-9 Overview (continued) In developing the interaction diagram for each system operation, we must assure that the operation: first checks whether every precondition of the contract is true, and then makes every postcondition of the contract come true.

10. © 2005 Prentice Hall8-10 Fundamental Concepts – Objects, Classes, and Messages Objects are the basic structural components of object-oriented software. They are organized into classes and communicate with each other by messages. Each object has three components: A unique identity A set of attributes (internal data) A set of behaviors (operations)

11. © 2005 Prentice Hall8-11 Fundamental Concepts – Objects Encapsulation protects the internal attributes and operations of an object from external access. Only public attributes and operations can be accessed from outside (via an interface). Objects in the application domain (business objects) are persistent.

12. © 2005 Prentice Hall8-12 Fundamental Concepts – Classes Every object is a member of a class – a group of objects with identical sets of attributes and behaviors. The value of an attribute can vary for objects in the same class. Classes may be organized as generalization-specialization hierarchies, with subclasses and superclasses.

13. © 2005 Prentice Hall8-13 Fundamental Concepts – Classes (continued) Each subclass inherits from its superclass. Every object in a subclass has: all the attributes of its superclass, all the operations of its superclass, and all the associations of its superclass, and may have additional attributes, operations, and associations.

14. © 2005 Prentice Hall8-14 Fundamental Concepts – Messages A message is a request from an object asking a second object to carry out a behavior (an operation) belonging to the second object. A message specifies: the identity of the object to which it is sent, the name of the operation, and possibly, the parameters of the message.

15. © 2005 Prentice Hall8-15 Fundamental Concepts – Messages (continued) Visibility: For an object (the client) to send a message to another object (the server), the receiving object must be visible to the sending object. (That is, it must know the server’s identity).

16. © 2005 Prentice Hall8-16 Fundamental Concepts – Messages (continued) Polymorphism: Objects in different classes may respond differently to messages with the same name.

17. © 2005 Prentice Hall8-17 Responsibilities The principal task of object-oriented program design is to assign responsibilities to classes. A responsibility is an obligation of an object to other objects.

18. © 2005 Prentice Hall8-18 Responsibilities (continued) An object may be responsible for knowing: What it knows – its attributes Who it knows – the objects associated with it What it knows how to do – the operations it can perform

19. © 2005 Prentice Hall8-19 Responsibilities (continued) An object may also be responsible for: Doing something itself Requesting services from other objects Controlling and coordinating the activities of other objects

20. © 2005 Prentice Hall8-20 Models and Techniques of Object-Oriented Program Design Class diagram Interaction diagrams Collaboration diagram Sequence diagram Contract Patterns Primary design criteria Coupling Cohesion Law of Demeter

21. © 2005 Prentice Hall8-21 Patterns for Object-Oriented Program Design A pattern is a named statement of a design problem together with its solution and guidance for applying the pattern. Patterns include: Façade Creator Expert Singleton

22. © 2005 Prentice Hall8-22 The Façade Pattern Problem: Who should be responsible for handling a system operation message from an actor? Solution: Assign this responsibility to an object representing the system as a whole.

23. © 2005 Prentice Hall8-23 The Creator Pattern Problem: Who should be responsible for requesting the creation of a new object, i. e., who sends the create message to the appropriate class? Solution: Assign this responsibility to a class which is in some way closely involved with the class. (See Figure 8.4 in text for details.)

24. © 2005 Prentice Hall8-24 The Expert Pattern Problem: What is the most basic principle for assigning responsibilities to objects? Solution: Assign the responsibility to the class which has the information necessary to fulfill it.

25. © 2005 Prentice Hall8-25 Interaction Diagrams An interaction diagram depicts the messages between objects or classes in a program. It shows collaborations between objects. The UML includes two types of interaction diagrams – collaboration diagrams and sequence diagrams.

26. © 2005 Prentice Hall8-26 Collaboration Diagrams A collaboration diagram is a network model of the messages between interacting objects and classes. There is a UML convention for numbering the messages to show the sequence in which they occur.

27. © 2005 Prentice Hall8-27 Collaboration Diagrams (continued).

28. © 2005 Prentice Hall8-28 Sequence Diagrams A sequence diagram shows interactions in a fence format. The messages appear from top to bottom in the sequence in which they occur.

29. © 2005 Prentice Hall8-29 Sequence Diagrams (continued).

30. © 2005 Prentice Hall8-30 Design Class Diagrams A design class diagram follows the same conventions as a domain model. However, it also shows the operations of the classes.

31. © 2005 Prentice Hall8-31 Design Class Diagrams (continued).

32. © 2005 Prentice Hall8-32 Procedure for Object-Oriented Program Design Step 1. Produce an interaction diagram for each system operation identified during analysis. Step 2. Produce a design class diagram showing the operations from the interaction diagrams. Step 3. Specify the signature and the algorithm for each operation.

33. © 2005 Prentice Hall8-33 Procedure for Object-Oriented Program Design (continued) Step 4. Design the graphical user interface. Step 5. Define the interface to the presentation layer. Step 6. Define the interface to the storage layer. Step 7. Place the classes in packages.

34. © 2005 Prentice Hall8-34 Collaboration Diagrams A collaboration diagram is a network model of messages between interacting objects or classes. Its components are: Objects or classes – shown as labeled rectangles Links (instances of associations) – shown as lines Messages – shown next to the links Arrows show the direction of messages.

35. © 2005 Prentice Hall8-35 Collaboration Diagrams (continued) The links are message paths. The sequence of messages is shown by a hierarchical numbering convention. The standard UML syntax for a message is: messageName (in parameter : parameterType, out parameter : parameterType)

36. © 2005 Prentice Hall8-36 Creating Collaboration Diagrams Step 1.1. Apply the Façade pattern. Choose a façade object for the system. Step 1.2. Apply the Creator pattern. Add new objects and their creators to the collaboration diagram. Step 1.3. Apply the Expert pattern. Assign every behavior to the object which is the information expert. Show the unknown client.

37. © 2005 Prentice Hall8-37 Creating Collaboration Diagrams (continued) Step 1.4. Paying attention to information flow, fill in the rest of the clients until there is a path of messages connecting all the objects. Step 1.5. Refine the collaboration diagram, taking into account coupling, cohesion, and the Law of Demeter.

38. © 2005 Prentice Hall8-38 A Public University Example.

39. © 2005 Prentice Hall8-39 A Public University Example (continued) Step 1.1. Apply the Façade pattern.

40. © 2005 Prentice Hall8-40 A Public University Example (continued) Step 1.2. Apply the Creator pattern.

41. © 2005 Prentice Hall8-41 A Public University Example (continued) Step 1.3. Apply the Expert pattern.

42. © 2005 Prentice Hall8-42 A Public University Example (continued) Step 1.3. Apply the Expert pattern.

43. © 2005 Prentice Hall8-43 A Public University Example (continued) Step 1.4. Considering information flow, provide a message path to every object.

44. © 2005 Prentice Hall8-44 Design Sequence Diagrams System sequence diagrams show only messages between the system and actors. Design sequence diagrams show all the messages between objects inside the system.

45. © 2005 Prentice Hall8-45 Creating Sequence Diagrams Automated tools convert collaboration diagrams to sequence diagrams and vice versa. Manual conversion involves using the sequence numbers in the collaboration diagrams to place the messages in the sequence diagram in order from top to bottom.

46. © 2005 Prentice Hall8-46 Creating Sequence Diagrams (continued).

47. © 2005 Prentice Hall8-47 Creating Sequence Diagrams (continued).

48. © 2005 Prentice Hall8-48 Summary Step 1 of object-oriented program design produces interaction diagrams (collaboration or sequence diagrams) for the system. The procedure applies the Façade, Creator, and Expert patterns and uses coupling, cohesion, and the Law of Demeter (Chapter 9) to develop and refine these diagrams.