SE 430 -- Object-oriented Modeling -- Session 7
Responsibilities, Contracts, Interaction Diagrams
Responsibility -- A contract or obligation of a class
Responsibilities become operations implemented as methods to
accomplish a task by the object acting alone or with the help of others.
Two Basic Responsibilities for objects
Knowing
Doing
Knowing responsibilities include an object’s awareness of
its own encapsulated data
its links to other objects
knowledge that it can derive or calculate
An object’s knowledge can be inferred from concept diagrams illustrating attributes and associations
Doing responsibilities include an object’s ability to
modify itself, create and link to other objects, or delete other objects and links
command other objects to take action
control or coordinate activity in other objects (collaboration)
System Sequence Diagrams
have the input events of a given use case that cause the system to respond
Input events become operations to the system.
Determine how the objects will interact to handle a given system operation
Make a contract for each system operation
identify the purpose of the operation (its responsibility)
establish preconditions -- what must be true before an operation can succeed
What attribute, links or classes must exist. The sender (client) is responsible for checking their existence prior to the operation.
identify post-conditions – the changes that exist after successful completion of the operation (what changes, not how).
Object changes include:
- instances created or deleted
- attributes modified
- links formed or broken
If a contract uncovers a hole in the model,
modify the model (add whatever is missing)
Larman’s Conceptual model for the Point of Sale System
Precondition:
What relevant objects and associations must exist prior to a Sale?
Postcondition:
When a Sale is successful,
what objects are created or deleted?
what links are made or broken?
what attributes are modified?
Name: / enterItem (upc:number,quantity:integer)Responsibilities: /
- Record sale of an item and add it to the sale.
- Display the item description and price.
Pre-conditions / UPC is known to the system
Post Conditions:
Exceptions: / If UPC is not valid, indicate an error
Obj. Created / Deleted Link Formed / Broken Attribute Modified / Details:
Instance Creation / If a new sale, a Sale was created
Link formed / If a new sale, the new Sale was associated with the POST
Instance Creation / A SalesLineItem was created
Link formed / A SalesLineItem was associated with the Sale
Attribute modified / SalesLineItem.quantity was set to quantity
Link formed / SalesLineItem associated with a ProductSpecification based on UPC match.
Name: / endSale( )
Responsibilities: / Record that it is the end of entry of sale items and display sale total
Obj. Created / Deleted Link Formed / Broken Attribute Modified / Details:
Attribute Modified / Sale.isComplete was set to true
Name: / makePayment(amount:Number)
Responsibilities: / Record the payment, calculate balance and print receipt
Obj. Created / Deleted Link Formed / Broken Attribute Modified / Details:
Instance Creation / Payment was created
Attribute Modified / Payment.amountTendered was set to amount
Link formed / Payment linked with Sale
Link formed / Sale linked with Store, to add it to historical log of completed sales
Use Case: / Start Up
Actors: / Manager
Type: / Primary
Description: / A Manager powers on a POST in order to prepare it for use by Cashiers. The Manager validates that the date and time are correct, after which the system is ready for Cashier use.
Name: / startUp ( )
Responsibilities: / Initialize the system
Obj. Created / Deleted Link Formed / Broken Attribute Modified / Details:
Instance Creation / Store, POST, Product Catalog and Product Specifications
Link formed / Product Catalog with Product Specifications
Link formed / Store with Product Catalog
Link formed / Store was linked with POST
Link formed / Post with Product Catalog
Design ------
Decide how the objects will work together to fill the contract
(dynamic behavior)
CRC cards and Robustness Diagrams
start the design process with approximate and informal solutions.
Use Interaction diagrams for more detailed solutions.
(Sometimes examination of details forces a revisit to previous decisions.)
Use interaction diagrams to
Allocate behavior among objects
Show the required detailed interactions among objects over time
Distribute operations among classes
(This may include adding objects or attributes to existing objects.)
Interaction Diagrams describehow
objects work together to fulfill the contract.
For each use case, an interaction diagram should be drawn
to describe the behavior of your system at run time
and how the system will accomplish that behavior.
- the typical course
- all alternate courses
Two types of interaction diagrams,
Sequence-- emphasizes the time order of events by
a clear sequencing of messages
Collaboration -- emphasizes the organization of objects by
showing their linkages
Sequence Diagrams -- Useful for displaying time sequences,
object activation and concurrent processes
To model a flow of control by time ordering,
- Select a use case
- Place icons at the top of the diagram for objects that exist prior to the start of the use case (most important objects on the left, least on the right)
- Set each object’s lifeline (a dashed vertical line beneath each object icon)
Each object has a lifeline for the length of its existence.
- For objects that exist throughout the use case, the lifeline is the length of the diagram
- For objects being created, show <create> message to icon. Lifeline follows point of creation
- For objects being destroyed, show <destroy> message to X which terminates lifeline.
- Starting with the first message that causes the interaction, connect the lifelines of the initiator of a message with the lifeline of the object that receives the message.
Time sequence -- Messages closer to the top occur earlier than messages closer to the bottom
Objects Created during the operation
have an object icon appear at the time they are created,
usually with a “create” message
Objects Deleted during the operation
have an X terminating their lifeline.
(an object can delete itself or be deleted by a message)
Textual descriptions
of the use case can be included on the left side of the page
parallel with the diagram messages.
Messages are indicated by a solid line with an arrow .
Three kinds of arrows
Arrow / Meaning / Arrow head styleSynchronous / Transfer control and wait for answer. (sequential operations) /
Asynchronous / Transfer control, don’t wait for answer. (concurrent operations) /
Return / Returns a value to the caller /
A message
- Has a message name (operation name):
endSale()
- Can have parameters used:setValue(3.4)
- Can have a return variable: area := getArea(length,width)
Messages can also have control information
iteration marker, iteration clause * : [for each item]
*[x := 1..10] Message will be sent 10 times
condition of execution
[check = true] Message if true
[check = false]Message if false
*[x < 10] Message sent until x becomes less than 10.
Return messages are optional -- use if they clarify, avoid if they add noise.
Some put named return values on return message
Indicate active objects by showing Focus of Control
Change an object’s lifeline to a thin rectangle when it is performing a computation,
Self-delegation / recursion -- shown by an object sending a message to itself
and a rectangle overlapping its current activity
Class Exercise: Create a sequence diagram for the following behavior
- The Order Entry Window sends a “prepare” message to an Order
- The Order then sends a “prepare” to each Order Line on the Order
- Each Order Line checks the given Stock Item
- If this check returns “true,” the Order Line removes the appropriate quantity of Stock Item from stock and creates a delivery item.
- If the Stock Item has fallen below the reorder level, that Stock Item requests a reorder.
6th Assignment (5 points)
Pick a use case and provide
Contracts for each system event
Sequence diagrams for each system event
1