Object Interaction modeling overview

Object interaction modeling demonstrates the dynamic behavior that occurs between objects by integrating the static object model with use cases. The object model defines the internal structure of objects but says nothing about how they inter-operate whereas use cases depict the operations between objects in the problem domain without concern for the internal composition of the objects themselves. You can model different aspects of the system domain, reflecting business needs from different user perspectives by depicting the interaction and messaging between objects in the system. Collectively these views and their underlying definitions are referred to as the object interaction model. The integration of use cases and class diagrams in the development of object sequence diagrams is an iterative process during which the use case model (the users view) and the class model (the developers view) is cross-checked with user requirements and refined. Object interaction modeling in Component Architect involves two types of modeling diagram derived from the object model and use cases: Object sequence diagram used to describe a use case or an operation in terms of the constructs of sequence, selection and iteration; the passage of time is depicted by an invisible time axis running downward through the diagram Object collaboration diagram used to describe a scenario or path within a use case; comprising objects and message flows between objects, in a snapshot of a time-lapse interaction; each path through the structured language of an object sequence diagram can be modeled by its own object collaboration diagram; typically only the most important scenarios are modeled with object collaboration diagrams. An object sequence diagram will map directly to one use case. A typical use case will consist of a set of scenarios, or paths, through the system being modeled representing different options within the use case. Each execution path can be represented by a unique object collaboration diagram. Therefore several object collaboration diagrams can map to one object sequence diagram.

Sequence diagram
A diagram that shows object interactions arranged in a time sequence. In particular, the sequence diagram shows the sequence of messages exchanged during the interaction. The sequence diagram can exist in a generic form, showing all possible scenarios, or in an instance form, showing a single scenario.

Object Sequence diagram overview

You use an OSD to show the interactions that occur between objects. The diagram is comprised of statements, objects and stimuli: Statements: A statement describes the processes which occur written in a form of structured English (additional view options can be used to show line numbering and loop connections known as construct balancing); statements are written down the left hand margin of the diagram; the vertical time axis is nonlinear and can be regarded as event driven

Objects and boundaries: Objects and boundaries are declared across the top of the diagram and modeled as vertical lines; objects can be classes or instances of classes; the order in which objects are placed on the diagram is not significant, however they should be arranged for maximum clarity Stimuli: A stimulus is shown in the form of a message between objects and probes. Drawing Icons: 1 2 3 4 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

9 10 11 12

13 14

15 16

17

18 19

Selection Note Frame bx Link note Sequence Selection statement Outcome Iteration Architecture boundary Actor Business class User class Interface class Exception class External item Operation Event Include probe Extend probe

Adding a statement A statement can be one of the following: selection statement iteration outcome

To insert a statement: Click the appropriate button for the new statement. Either click at the bottom of the Description column on the diagram to append a statement. Or click on any permitted point within the Description column to insert a statement. A default statement is displayed which you can edit, move or indent. To edit a statement: Click the default text to display the Property pages. Use the Full Text editor to write the statement in structured English.

Adding a class to an OSD A class can be one of the following: business class user class external class or interface interface

To use the button bar to add an instance of a new class: Click the appropriate button Click the appropriate part of the diagram The class is displayed as an instance To add an instance of an existing class: Right-click on the diagram where you want the instance to appear Choose Add, Class Select a class name from the list The class is displayed as an instance To display an instance as a class: Right-click the instance on the diagram, select Instance properties Click Options Check Anonymous to show the item as a class Uncheck Anonymous to show the item as an instance.

Adding stimuli
Using the button bar to add an operation or event to an OSD: A message stimulus can be one of the following operation event Click the appropriate button Click the source instance or class Click the destination instance or class Either enter a new operation or event or select an existing item from the displayed list Adding an operation or event from the dictionary Drag the selected item to the source instance or class Select the destination instance or class from the displayed list. Using the button bar to add a uses or extends probe to an OSD: Adding a probe: A probe can be one of the following: uses probe extends probe Click the appropriate button Click the source instance or class The probe is drawn to a default position on the diagram If required, drag the end of the probe to a more suitable position Adding a use case from the dictionary as a probe: 3

Drag the selected use case to the source instance or class Select Uses probe or Extends probe from the menu.

Defining an operation on an OSD

You can use the Properties, Options tab to define an operation on an object sequence diagram in the following way: Access: Define the visibility of the operation as follows: Public access so that it is visible to all derived classes and instances. Protected access so that it is visible to all derived classes. Package Protected access so that it is visible to all derived classes, only within the package. Private access so that it is visible only to the owner class. Binding: Specify whether binding is static or dynamic as follows: At Compile to define that the binding is static, assuming that there will be no refinement of the operation. At Runtime (for virtual, or dynamic, binding) when you expect the operation to be refined. Static: When checked, the operation to On Class, and the the name of the operation is underlined in the diagram. (Underlining is the conventional way to indicate a class-scope operation on a diagram.) When not checked, the operation is On Instance, and the the name of the operation is not underlined in the diagram. This option is not available for an external attribute or operation. Asynchronous: When checked, the operation on an interface is Asynchronous. With this checked, the the sending object does not wait for a result. When checked, the arrowhead of the operation on the diagram is open. When not checked, the arrowhead of the operation on the diagram is closed. Asynchronous checked Asynchronous not checked Abstract operation: When checked, the operation is Abstract. An abstract operation is one containing no implementation; it should be overridden by the implementation of an operation at another level. If a class contains an abstract operation, the class itself becomes abstract. Immutable: When checked, the operation is Immutable. An immutable operation does not change the state or any member variables (attributes) of the class.

Defining the parent of an OSD

An object sequence diagram can be the child of a use case, operation or event in the dictionary and of a probe, operation or event on the diagram. To create a new OSD as the child of a dictionary item: Right-click on the appropriate parent in the dictionary 4

Choose New, Object sequence diagram To create a new OSD as the child of an item on the diagram: Right-click on the appropriate parent on the diagram Choose New, Object sequence diagram To define a dictionary item as a parent of an existing OSD Open an OSD that does not have a parent Click on the appropriate parent in the dictionary Drag the parent to the top left corner of the diagram To define a diagram item as the parent of an existing OSD Right-click on the appropriate parent on the diagram Choose Links, Child diagrams Use the Links editor to select a permitted child diagram.

Displaying construct balancing and line numbers

To display PDL statement construct balance brackets and line numbering in an OSD: Right-click in free space on an OSD Choose View options, Diagram Check Show construct balancing and Show line numbers as required.

Moving a boundary
To move a boundary: Click on a boundary to select it Drag the boundary to a new position Note: The system boundary can only be moved within the area to the left of the architectural boundary.