Chapter 11 Following the Trail; Examining Execution Sequences

Chapter 11: Responsibilities and Collaborations 11.1. Objects and Responsibilities 11.2. Contracts 11.3. Collaborations 11.4. CRC Cards 11.5. Identifying Responsibilities 11.6. Assigning Responsibilities 11.7. Identifying Collaborations 11.8. Sequence Diagrams

Chapter 11: Responsibilities and Collaborations 11.1. Objects and Responsibilities 11.2. Contracts 11.3. Collaborations 11.4. CRC Cards 11.5. Identifying Responsibilities 11.6. Assigning Responsibilities 11.7. Identifying Collaborations 11.8. Sequence Diagrams

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

to provide that service when requested Chapter 11: Responsibilities and Collaborations 11.1. Objects and Responsibilities. Wherever a service exists, we can say there is a Responsibility to provide that service when requested to those who need it.

“Responsibilities include two key items: Chapter 11: Responsibilities and Collaborations 11.1. Objects and Responsibilities. “Responsibilities include two key items: The knowledge that an object maintains (i.e., the data it carries), And the actions an object can perform (i.e., its behaviors.)” Rebecca Wirfs-Brock et al. (1990)

The knowledge (data) implies: Chapter 11: Responsibilities and Collaborations 11.1. Objects and Responsibilities. The knowledge (data) implies: a group of responsibilities to provide the attribute values to an Actor, i.e., to any (qualified) person who asks. Some Actors will simply request values, others will update values, or create or delete Instances.

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

The Invoice has a responsibility to Chapter 11: Responsibilities and Collaborations 11.1. Objects and Responsibilities. The Invoice has a responsibility to ensure that the Account Balance is updated. This responsibility it then delegates to the Account object. The Account object has a responsibility to update its Balance attribute.

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

Chapter 11: Responsibilities and Collaborations 11.1. Objects and Responsibilities 11.3. Collaborations 11.4. CRC Cards 11.5. Identifying Responsibilities 11.6. Assigning Responsibilities 11.7. Identifying Collaborations 11.8. Sequence Diagrams 11.2. Contracts

Chapter 11: Responsibilities and Collaborations 11.2. Contracts. The “agreement” between two classes is such that: When, say, a Customer object sends a message, The chosen Invoice object will provide a service by printing itself.

Chapter 11: Responsibilities and Collaborations 11.2. Contracts. Webster defines a contract as: “A binding agreement between two or more persons or parties.” Wirfs-Brock et al (1990) describe a contract as: “ A list of services an instance of one class can request from an instance of another.”

Chapter 11: Responsibilities and Collaborations 11.2. Contracts. Note this is a Client-Server relationship, Where the client requests a service, From the Server object, and expects that it will be done. But sometimes the server needs help to do its task . . .

Chapter 11: Responsibilities and Collaborations 11.1. Objects and Responsibilities 11.2. Contracts 11.4. CRC Cards 11.5. Identifying Responsibilities 11.6. Assigning Responsibilities 11.7. Identifying Collaborations 11.8. Sequence Diagrams 11.3. Collaborations

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

Chapter 11: Responsibilities and Collaborations 11.3. Collaborations. Often a service needed by a client Requires data that the server doesn’t have, Or tasks that the server doesn’t know how to do, So the server calls on other classes for help. Object #1 #2 Request for service Response Client Server It starts like this:

Chapter 11: Responsibilities and Collaborations 11.3. Collaborations. Then the server asks for help: Object #1 #2 Request for service Response Client Server #3 Request for assistance Help response Note that for this request, the server is now a client.

Chapter 11: Responsibilities and Collaborations 11.3. Collaborations. This we call a collaboration, A request from a client to a server, for a service that will help the client fulfil one of its own responsibilities.

Chapter 11: Responsibilities and Collaborations 11.3. Collaborations. Wirfs-Brock has endorsed and promoted a handy tool for finding Responsibilities and Collaborations . . .

Chapter 11: Responsibilities and Collaborations 11.1. Objects and Responsibilities 11.2. Contracts 11.3. Collaborations 11.5. Identifying Responsibilities 11.6. Assigning Responsibilities 11.7. Identifying Collaborations 11.8. Sequence Diagrams 11.4. CRC Cards

There is one card per class. Write the class details at the top. Chapter 11: Responsibilities and Collaborations 11.4. Class Cards (CRC Cards). There is one card per class. Write the class details at the top. The left column is for the responsibilities, The right column is for the collaborating classes (or the method in the collaborating class.)

Here is a CRC Card for a Library Book: Chapter 11: Responsibilities and Collaborations 11.4. Class Cards (CRC Cards). Class: Identifier Book Book No. Responsibilities Collaborations Know Book No. Know Title Know Author Know Date Published Know Date Purchased Know Purchase Price Know Depreciated Value Know Date Last Out Know Date Last In Know Date last Shelved Here is a CRC Card for a Library Book: SignBookOut Subscriber Sign-Out CheckBookIn Sign-Out ShelveBook

Chapter 11: Responsibilities and Collaborations 11. 4 Chapter 11: Responsibilities and Collaborations 11.4. Class Cards (CRC Cards). Know Invoice no. Know Customer No. Class: Identifier Responsibilities Collaborations Invoice Invoice No. Know Invoice No. Know Customer No. Print Invoice Calculate Invoice Total Line Item Class: Identifier Line Item Invoice No. + Line No. Responsibilities Collaborations Know Invoice No. Know Line No. Know Product Code Know Quantity Sold Know Unit of Measure Know Actual Unit Price CalculateExtendedPrice PrintLineItem Product Tax Rate The Invoice Example

Chapter 11: Responsibilities and Collaborations 11. 4 Chapter 11: Responsibilities and Collaborations 11.4. Class Cards (CRC Cards). Class: Identifier Invoice Invoice No. Receivables Account Account No. Responsibilities Collaborations Know Invoice no. Know Customer No. Know Account No. Know Customer No. Know Description Know Balance Know Balance 30 Days Know Balance 60 Days Know Balance 90 Days Identifier Responsibilities Collaborations Class: Receivables Transaction Transaction No. Know Account No. Know Transaction No. Know Date Know Cash Amount PostToAccount PrintStatementLine Print Statement AddTransactionToBalance Receivables Transaction The Invoice Example

So for now we are . . . Finding names for the behaviors. Chapter 11: Responsibilities and Collaborations 11.4. Class Cards (CRC Cards). To fill in the cards, there are a number of ideas Wirfs-Brock recommends for finding and naming Responsibilities Remember, at Analysis that’s our goal: Finding names for the behaviors. Later, at design time, we will spec them out in detail. So for now we are . . .

Chapter 11: Responsibilities and Collaborations 11.1. Objects and Responsibilities 11.2. Contracts 11.3. Collaborations 11.4. CRC Cards 11.6. Assigning Responsibilities 11.7. Identifying Collaborations 11.8. Sequence Diagrams 11.5. Identifying Responsibilities

First, enter all the “Know” responsibilities. Chapter 11: Responsibilities and Collaborations 11.5. Identifying Responsibilities. First, enter all the “Know” responsibilities. Basically, each attribute must have: An Update responsibility, and A Provide-the-value-to-those-who-need-it For these, we may wish to group attributes in related clusters. Then enter any other behaviors that we’re already aware of.

Use Case Scenarios Walk-through the system, Using the Use Cases. Chapter 11: Responsibilities and Collaborations 11.5. Identifying Responsibilities. Use Case Scenarios Walk-through the system, Using the Use Cases. As Actors (users) walk through each Use Case, Note which class is being queried or updated at each step of the procedure. Then check if an appropriate responsibility has already been identified, And if not then add it.

Chapter 11: Responsibilities and Collaborations 11. 5 Chapter 11: Responsibilities and Collaborations 11.5. Identifying Responsibilities. Input/Output Data transfers require at least Update and Provide responsibilities, and often Validate as well, and Report Errors. Output: Provide Data and Format, Calculations, Graphics, etc.

Chapter 11: Responsibilities and Collaborations 11. 5 Chapter 11: Responsibilities and Collaborations 11.5. Identifying Responsibilities. User Interactions To get even more value from the Use cases, Bring in additional users to do more walk-thrus. Watch especially for “what-ifs” that may not have been noticed earlier.

Prompts and Error Messages Chapter 11: Responsibilities and Collaborations 11.5. Identifying Responsibilities. Prompts and Error Messages We may already be aware of some from our earlier work. Each prompt represents input, So some class has a Receive responsibility. Each Error message represents a responsibility to test for some condition, And to report on it.

Instance Creation and Deletion Chapter 11: Responsibilities and Collaborations 11.5. Identifying Responsibilities. Instance Creation and Deletion Every class has a responsibility to crate instances of itself, And may need more than one way to do it (i.e., several «create» methods). Every class has a responsibility to delete or archive unwanted instances. Others may go into a “suspense” state while awaiting final archiving or deletion

all the responsibilities, there is a check to do Chapter 11: Responsibilities and Collaborations 11.5. Identifying Responsibilities. Once we find all the responsibilities, there is a check to do to ensure that each one is in the appropriate class . . .

Chapter 11: Responsibilities and Collaborations 11.1. Objects and Responsibilities 11.2. Contracts 11.3. Collaborations 11.4. CRC Cards 11.5. Identifying Responsibilities 11.7. Identifying Collaborations 11.8. Sequence Diagrams 11.6. Assigning Responsibilities

For most responsibilities it’s obvious Chapter 11: Responsibilities and Collaborations 11.6. Assigning Responsibilities. For most responsibilities it’s obvious which class they belong in. Normalization requires data be grouped by the class it describes, and encapsulation requires that the code to manipulate it be in the same class.

Wirfs-Brock’s Power Principle Chapter 11: Responsibilities and Collaborations 11.6. Assigning Responsibilities. Wirfs-Brock’s Power Principle If all the “power” and “intelligence” in a system Is in just a few classes, They become unwieldy, And re-useability is reduced. So we may need to: Split a class into two or more, or Re-assign some responsibilities to other classes.

Chapter 11: Responsibilities and Collaborations 11.1. Objects and Responsibilities 11.2. Contracts 11.3. Collaborations 11.4. CRC Cards 11.5. Identifying Responsibilities 11.6. Assigning Responsibilities 11.8. Sequence Diagrams 11.7. Identifying Collaborations

These questions must be asked about each Chapter 11: Responsibilities and Collaborations 11.7. Identifying Collaborations. These questions must be asked about each responsibility we have discovered: Does this class have everything it needs to do this? If not, what is missing? What data is missing? What additional tasks are needed before, during, or after the main task?

What classes in the model can supply these? Chapter 11: Responsibilities and Collaborations 11.7. Identifying Collaborations. What classes in the model can supply these? Can any of them? If so, record the collaboration. If not, then Add an attribute or responsibility, or Define a new class, or Browse available class libraries.

Follow the chain to its end right now while the trail is still warm Chapter 11: Responsibilities and Collaborations 11.7. Identifying Collaborations. Sometimes a client responsibility Requires help from a contracting server, Who needs a “subcontractor” Who needs another one, and so on. When this happens, Follow the chain to its end right now while the trail is still warm

Then we approach it from the other view: Chapter 11: Responsibilities and Collaborations 11.7. Identifying Collaborations. Then we approach it from the other view: What significant data does this class carry? What important things can it do? Who needs it? What other classes might need the data require the services of this class.

Chapter 11: Responsibilities and Collaborations 11.1. Objects and Responsibilities 11.2. Contracts 11.3. Collaborations 11.4. CRC Cards 11.5. Identifying Responsibilities 11.6. Assigning Responsibilities 11.7. Identifying Collaborations 11.8. Sequence Diagrams

from the point of view of Chapter 11: Responsibilities and Collaborations 11.8. Sequence Diagrams A CRC Card: Documents the interactions among objects i.e., the method calls and data transfers from the point of view of one class at a time

Shows the complete pattern of method calls and collaborations Chapter 11: Responsibilities and Collaborations 11.8. Sequence Diagrams A CRC Card: Shows the complete pattern of method calls and collaborations for that class

Society of Objects A Sequence Diagram: Chapter 11: Responsibilities and Collaborations 11.8. Sequence Diagrams On the other hand, A Sequence Diagram: Documents those same interactions, showing the pattern of calls among a Society of Objects (i.e., a bunch of objects that regularly hold conversations)

Begin by following a use case Chapter 11: Responsibilities and Collaborations 11.8. Sequence Diagrams Begin by following a use case Follow our CRC cards Update cards where needed At the same time map the steps on a sequence diagram . . .

Objects are shown along the top. Chapter 11: Responsibilities and Collaborations 11.8. Sequence Diagrams :Window :Position Steve:Manager Old:Occupancy Joe: Objects are shown along the top. Use a class name Or an instance name Or both. The colon ( : ) comes after the instance name and before the class name

t The vertical axis is Time Shown as dashed lines, and reading down Chapter 11: Responsibilities and Collaborations 11.8. Sequence Diagrams :Window :Position Old:Occupancy Steve:Manager Joe: t The vertical axis is Time Shown as dashed lines, and reading down Each vertical Time axis is called a Lifeline

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

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

Chapter 11: Responsibilities and Collaborations 11. 8 Chapter 11: Responsibilities and Collaborations 11.8. Sequence Diagrams :Window :Position Old:Occupancy Steve:Manager Joe: displayPosName(posNo) New: Occupancy archiveOldOccupancy(date) « create » success() advise() Then we send a message to « create » a new Occupancy instance Then a pair of unanswered messages to advise the Manager and Employee instances These ones are asynchronous Signals.

Summary: So we work through our use case Using our CRC cards Chapter 11: Responsibilities and Collaborations 11.8. Sequence Diagrams Summary: So we work through our use case Using our CRC cards Drawing a Sequence Diagram as we go And adding to the CRC cards as needed.

End of Chapter 11