1. 1 Examining Execution Sequences Introducing Sequence Diagrams

2. 2 real-world Takes a real-world view of objects and classes. purpose The purpose of having an object with data do something is so that it can do something for us. Responsibility So it has a Responsibility to do what we need, Service that is, to provide a Service to us or some other object, possibly a User object. Responsibility-Driven Design (RDD)

3. 3 we can say there is a Responsibility to provide that service when requested to those who need it. Wherever a service exists,

4. 4 The knowledge that an object maintains (i.e., the data it carries), And the actions an object can perform (i.e., its behaviors.)” Responsibilities include two key items:

5. 5 actions The actions (behaviors) each imply do something, a Responsibility to do something, e.g.: Invoice print itself, An Invoice has a responsibility to print itself, update Total And to update its Total attribute, print TaxGrand Total. Calculate and print its Tax and Grand Total. Line Item calculate Extended Price, A Line Item has a responsibility to calculate and return its Extended Price, print itself. And to print itself.

6. 6 Invoice The Invoice has a responsibility to ensure that the Account Balance is updated. Account This responsibility it then delegates to the Account object. Account Balance The Account object has a responsibility to update its Balance attribute.

7. 7 In this scenario, no responsibility The invoice has no responsibility to advise the Customer when it has been printed, Usernot But it must notify the User if it can not complete its assigned task. l In this sense we can say that there is an Agreement, Contract Agreement, or a Contract between the two classes of objects.

8. 8 l When, say, a Customer object sends a message, provide a service The chosen Invoice object will provide a service by printing itself. The “agreement” between two classes is such that:

9. 9 “ A list of services an instance of one class can request from can request from an instance of another.” Wirfs-Brock et al (1990) describe a contract as:

10. 10 l Where the client requests a service from the Server object l But sometimes the server needs help to do its task... Note this is a Client-Server relationship,

11. 11 l The Invoice was unable to do the job alone, l And had to ask for help Line Item Account From the Line Item and Account classes. updating It delegated the updating to the Account class, multiplying Quantity by Unit Price And multiplying Quantity by Unit Price to the Line Item class. In the last scenario,

12. 12 Requires data that the server doesn’t have, l Or tasks that the server doesn’t know how to do, l So the server calls on other classes for help. l Often a service needed by a client

13. 13 Object #1 Object #2 Request for service Response ClientServer It starts like this:

14. 14 Object #1 Object #2 Request for service Response ClientServer Then the server asks for help: Object #3 Request for assistance Help response ServerClient

15. 15 Note that for this request, the server is now a client. Note that for this request, the server is now a client. Object #1 Object #2 Object #3 Request for service Request for assistance Help response Response ClientServerServerClient

16. 16 A request from a client to a server, for a service that will help the client fulfill one of its own responsibilities. collaboration This we call a collaboration

17. 17 l As Actors (users) walk through each Use Case l Note which class is being queried or updated at each step of the procedure. l Then check if an appropriate responsibility has already been identified, l And if not then add it. Use Case Scenarios l Walk-through the system,

18. 18 l Does this class have everything it needs to do this? l If not, what is missing? l What data is missing? l What additional tasks are needed n before, n during, or n After the main task? These questions must be asked about each responsibility you have discovered:

19. 19 l Can any of them? l If so, record the collaboration. l If not, then n Add an attribute or responsibility, or n Define a new class, or n Browse available class libraries. What classes in the model can supply these additional tasks?

20. 20 l Requires help from a contracting server, l Who needs a “subcontractor” l who needs another one, and so on. l Sometimes a client responsibility

21. 21 l Documents these interactions, showing the pattern of calls among a Society of Objects (i.e., a bunch of objects that regularly hold conversations – might constitute a subsystem) A Sequence Diagram:

22. 22 class name Use a class name l Objects are shown along the top. : after before The colon ( : ) comes after the instance name and before the class name :Window :Position l Or both. Joe: instance name Or an instance name Steve:ManagerOld:Occupancy

23. 23 Time The vertical axis is Time Steve:Manager :Window :Position Joe: Old:Occupancy l Shown as dashed lines, and reading down t Lifeline Each vertical Time axis is called a Lifeline

24. 24 l We place a skinny box on each lifeline Chapter 11: Responsibilities and Collaborations 11.8. Sequence Diagrams Steve:Manager :Window :Position Joe: Old:Occupancy focus of control This is called a focus of control activation line or an activation line l It shows what part of its life the object is active t

25. 25 Position l To begin handling a “Promotion”, a screen object queries a Position instance. :Window l A dashed arrow indicates the response Joe: Steve:Manager :Position displayPosName(posNo) l Then the screen object sends a message to archive the old position occupancy data, with today’s date as parameter Old:Occupancy archiveOldOccupancy(date)

26. 26 Joe: success() archiveOldOccupancy(date) displayPosName(posNo) « create » Occupancy l Then we send a message to « create » a new Occupancy instance :Window unanswered l Then a pair of unanswered messages to advise the Manager and Employee instances Steve:Manager Old:Occupancy :Position New: Occupancy « create » advise()