UNIT -2 Part 1

Basic Structural Modelling

[Link]
Classes are the most important building block of any object-oriented system. A class is a
description of a set of objects that share the same attributes, operations, relationships, and
semantics. A class implements one or more interfaces.
You use classes to capture the vocabulary of the system you are developing. These classes
may include abstractions that are part of the problem domain, as well as classes that make
up an implementation.
You can use classes to represent software things, hardware things, and even things that are
purely conceptual.

Graphically, a class is rendered as a rectangle.

Figure : Classes

Names
A class name must be unique within its enclosing package. Every class must have a name
that distinguishes it from other classes. A name is a textual string. That name alone is
known as a simple name; a path name is the class name prefixed by the name of the
package in which that class lives. A class may be drawn showing only its name, as Figure
shows.

Figure : Simple and Path Names

Attributes
Attributes are related to the semantics of aggregation. An attribute is a named property of
a class that describes a range of values that instances of the property may hold. A class may
have any number of attributes or no attributes at all. An attribute represents some property
of the thing you are modeling that is shared by all objects of that class.
For example, every wall has a height, width, and thickness; you might model your
customers in such a way that each has a name, address, phone number, and date of birth.
An attribute is therefore an abstraction of the kind of data or state an object of the class
might encompass. At a given moment, an object of a class will have specific values for
every one of its class's attributes.
Graphically, attributes are listed in a compartment just below the class name. Attributes
may be drawn showing only their names, as shown in Figure .
 Figure : Attributes

You can further specify an attribute by stating its class and possibly a default initial value, as
shown Figure
Figure :Attributes and Their Class

Operations
An operation is the implementation of a service that can be requested from any object of
the class to affect behavior. In other words, an operation is an abstraction of something you
can do to an object and that is shared by all objects of that class. A class may have any
number of operations or no operations at all. For example, in a windowing library such as
the one found in Java's awt package, all objects of the class Rectangle can be moved,
resized, or queried for their properties. Often (but not always), invoking an operation on an
object changes the object's data or state. Graphically, operations are listed in a
compartment just below the class attributes. Operations may be drawn showing only their
names, as in Figure .
Figure : Operations

Organizing Attributes and Operations

When drawing a class, you don't have to show every attribute and every operation at once.
In fact, in most cases, you can't (there are too many of them to put in one figure) and you
probably shouldn't (only a subset of these attributes and operations are likely to be relevant
to a specific view). For these reasons, you can elide a class, meaning that you can choose to
show only some or none of a class's attributes and operations. An empty compartment
doesn't necessarily mean there are no attributes or operations, just that you didn't choose to
show them. You can explicitly specify that there are more attributes or properties than
shown by ending each list with an ellipsis ("...").

To better organize long lists of attributes and operations, you can also prefix each group
with a descriptive category by using stereotypes, as shown in Figure .
 Figure : Stereotypes for Class Features

Responsibilities
Responsibilities are an example of a defined stereotype. A responsibility is a contract or an
obligation of a class. When you create a class, you are making a statement that all objects
of that class have the same kind of state and the same kind of behavior. At a more abstract
level, these corresponding attributes and operations are just the features by which the
class's responsibilities are carried out. A Wall class is responsible for knowing about
height, width, and thickness Graphically, responsibilities can be drawn in a separate
compartment at the bottom of the class icon, as shown in Figure .
Figure : Responsibilities

Responsibilities are just free-form text. In practice, a single responsibility is written as a

phrase, a sentence, or (at most) a short paragraph.

[Link]

Figure : Relationships
A relationship is a connection among things. In object-oriented modeling, there are three
kinds of relationships that are especially important: dependencies, which represent using
relationships among classes (including refinement, trace, and bind relationships);
generalizations, which link generalized classes to their specializations; and associations,
which represent structural relationships among objects.
Dependency
A dependency is a using relationship that states that a change in specification of one thing
(for example, class Event) may affect another thing that uses it (for example, class
Window),
but not necessarily the reverse. Graphically, a dependency is rendered as a dashed directed
line, directed to the thing being depended on. Use dependencies when you want to show
one thing using another.
Figure : Dependencies

A dependency can have a name, although names are rarely needed unless you have a model
with many dependencies and you need to refer to or distinguish among dependencies. More
commonly, you'll use stereotypes to distinguish different flavors of dependencies.
Generalization
A generalization is a relationship between a general thing (called the superclass or
parent)and a more specific kind of that thing (called the subclass or child). Generalization
is sometimes called an "is-a-kind-of" relationship: one thing (like the class BayWindow) is-
a- kind-of a more general thing (for example, the class Window). Generalization means
that objects of the child may be used anywhere the parent may appear, but not the reverse.
Graphically, generalization is rendered as a solid directed line with a large open arrowhead,
pointing to the parent, as shown in Figure. Use generalizations when you want to show
parent/child relationships.
Figure: Generalization

A class may have zero, one, or more parents. A class that has no parents and one or more
children is called a root class or a base class. A class that has no children is called a leaf
class. A class that has exactly one parent is said to use single inheritance; a class with more
than one parent is said to use multiple inheritance.
Association
An association is a structural relationship that specifies that objects of one thing are
connected to objects of another. Given an association connecting two classes, you can
navigate from an object of one class to an object of the other class, and vice versa. It's quite
legal to have both ends of an association circle back to the same class. This means that,
given an object of the class, you can link to other objects of the same class. An association
that connects exactly two classes is called a binary association. Although it's not as
common, you can have associations that connect more than two classes; these are called
n-ary association. Graphically, an Association is rendered as a solid line connecting the
same or different classes .
Use associations when you want to show structural relationships.

Beyond this basic form, there are four adornments that apply to associations.
Name
An association can have a name, and you use that name to describe the nature of the
relationship. So that there is no ambiguity about its meaning, you can give a direction to the
name by providing a direction triangle that points in the direction you intend to read the
name, as shown in Figure
Figure: Association Names

Role
When a class participates in an association, it has a specific role that it plays in that
relationship; a role is just the face the class at the near end of the association presents to the
class at the other end of the association. You can explicitly name the role a class plays in an
association. In Figure, a Person playing the role of employee is associated with a Company
playing the role of employer.
Figure: Roles

Multiplicity
An association represents a structural relationship among objects. In many modeling
situations, it's important for you to state how many objects may be connected across an
instance of an association. This "how many" is called the multiplicity of an association's
role, and is written as an expression that evaluates to a range of values or an explicit value
as in Figure 5-6. When you state a multiplicity at one end of an association, you are
specifying that, for each object of the class at the opposite end, there must be that many
objects at the near end. You can show a multiplicity of exactly one (1), zero or one (0..1),
many (0..*), or one or more (1..*). You can even state an exact number (for example, 3).
Figure : Multiplicity

You can specify more complex multiplicities by using a list, such as 0..1, 3..4, 6..*, which
would mean "any number of objects other than 2 or 5."
Aggregation
A plain association between two classes represents a structural relationship between peers,
meaning that both classes are conceptually at the same level, no one more important than
the other. Sometimes, you will want to model a "whole/part" relationship, in which one
class represents a larger thing (the "whole"), which consists of smaller things (the "parts").
This kind of relationship is called aggregation, which represents a "has-a" relationship,
meaning that an object of the whole has objects of the part. Aggregation is really just a
special kind of association and is specified by adorning a plain association with an open
diamond at the whole end, as shown in Figure.
Figure : Aggregation

The meaning of this simple form of aggregation is entirely conceptual. The open diamond
distinguishes the "whole" from the "part," no more, no less. This means that simple
aggregation does not change the meaning of navigation across the association between the
whole and its parts, nor does it link the lifetimes of the whole and its parts.

[Link] Mechanisms
The UML is made simpler by the presence of four common mechanisms that apply
consistently throughout the language:
 Specifications
 Adornments
 Common divisions
 Extensibility mechanisms

Specifications
The UML is more than just a graphical language. Rather, behind every part of its graphical
notation there is a specification that provides a textual statement of the syntax and
semantics of that building block. For example, behind a class icon is a specification that
provides the full set of attributes, operations (including their full signatures), and behaviors
that the class embodies;
Adornments
Notes are the most important kind of adornment that stands alone. A note is a graphical
symbol for rendering constraints or comments attached to an element or a collection of
elements.

Most elements in the UML have a unique and direct graphical notation that provides a
visual representation of the most important aspects of the element. A class's specification
may include other details, such as whether it is abstract or the visibility of its attributes and
operations. Many of these details can be rendered as graphical or textual adornments to the
class's basic rectangular notation.
 For example, Figure shows a class, adorned to indicate that it is an abstract class with two
public, one protected, and one private operation. Every element in the UML's notation
starts with a basic symbol, to which can be added a variety of adornments specific to that
symbol.
Common Divisions
In modeling object-oriented systems, the world often gets divided in at least a couple of
ways.
1. class and object
2. interface and implementation
Extensibility Mechanisms
The UML's extensibility mechanisms permit you to extend the language in controlled
ways.
The UML provides a standard language for writing software blueprints, but it is not
possible for one closed language to ever be sufficient to express all possible nuances of all
models across all domains across all time. The UML's extensibility mechanisms include
1. Stereotypes
2. Tagged values
3. Constraints

1. Stereotypes
A stereotype extends the vocabulary of the UML, allowing you to create new kinds of
building blocks that are derived from existing ones but that are specific to your problem.
For example, if you are working in a programming language, such as Java or C++, you will
often want to model exceptions. In these languages, exceptions are just classes, You can
make exceptions first class citizens in your models, meaning that they are treated like basic
building blocks, by marking them with an appropriate stereotype, as for the class Overflow
in Figure.

2. Tagged values
A tagged value extends the properties of a UML building block, allowing you to create new
information in that element's specification. For example, if you want to specify the version
and author of certain critical abstractions. Version and author are not primitive UML
concepts. For example, the class EventQueue is extended by marking its version and author
explicitly.
3. Constraints
A constraint extends the semantics of a UML building block, allowing you to add new
rules or modify existing ones. For example, you mght want to constrain the EventQueue
class so that all additions are done in order. As Figure above, you can add a constraint that

explicitly marks these for the operation add.

Figure :Stereotypes, Tagged Values, and
Constraints
Figure: Stereotypes
Figure :Tagged Values
Figure : Constraint
5. Class Diagrams
Class diagrams are the most common diagram found in modeling object- oriented systems.
A class diagram shows a set of classes, interfaces, and collaborations and their
relationships. You use class diagrams to model the static design view of a system. For the
most part, this involves modeling the vocabulary of the system, modeling collaborations, or
modeling schemas.
Class diagrams are also the foundation for a couple of related diagrams: component
diagrams and deployment diagrams.
Terms and Concepts
A class diagram is a diagram that shows a set of classes, interfaces, and collaborations and
their relationships. Graphically, a class diagram is a collection of vertices and arcs.
Contents
Class diagrams commonly contain the following things:
· Classes
· Interfaces
· Collaborations
· Dependency, generalization, and association relationships

With the UML, you use class diagrams to visualize the static aspects of these building
blocks and their relationships and to specify their details for construction, as you can see in
Figure .
Figure : Class Diagram
 Common Uses
You use class diagrams to model the static design view of a system. This view primarily
supports the functional requirements of a system• the services the system should provide to its
end users.
When you model the static design view of a system, you'll typically use class diagrams in
one of three ways.
1. To model the vocabulary of a system
Modeling the vocabulary of a system involves making a decision about which abstractions
are a part of the system under consideration and which fall outside its boundaries. You use
class diagrams to specify these abstractions and their responsibilities.
2. To model simple collaborations
A collaboration is a society of classes, interfaces, and other elements that work together to
provide some cooperative behavior that's bigger than the sum of all the elements. For
example, when you're modeling the semantics of a transaction in a distributed system, you
can't just stare at a single class to understand what's going on. Rather, these semantics are
carried out by a set of classes that work together. You use class diagrams to visualize and
specify this set of classes and their relationships.
3. To model a logical database schema
Think of a schema as the blueprint for the conceptual design of a database. In many
domains, you'll want to store persistent information in a relational database or in an object-
oriented database. You can model schemas for these databases using class diagrams.

Common
ModelingTechniques
1.
ModelingSimpleCollaboration

No class stands alone. Rather, each works in collaboration with others to carry out some
semantics greater than each individual. Therefore, in addition to capturing the vocabulary
of your system, you'll also need to turn your attention to visualizing, specifying,
constructing, and documenting the various ways these things in your vocabulary work
together. You use class diagrams to represent such collaborations.
To model a collaboration,
 Identify the mechanism you'd like to model. A mechanism represents some function or
behavior of the part of the system you are modeling that results from the interaction of a
society of classes, interfaces, and other things.
 For each mechanism, identify the classes, interfaces, and other collaborations that
participate in this collaboration. Identify the relationships among these things, as well.
 Use scenarios to walk through these things. Along the way, you'll discover parts of your
model that were missing and parts that were just plain semantically wrong.
 Be sure to populate these elements with their contents. For classes, start with getting a good
balance of responsibilities. Then, over time, turn these into concrete attributes and
operations.
The figure focuses on the classes involved in the mechanism for moving the robot along a
path. You'll find one abstract class (Motor) with two concrete children, Steering Motor and
Main Motor. Both of these classes inherit the five operations of their parent, Motor.
 2. Modeling a Logical Database Schema

Many of the systems you'll model will have persistent objects, which means that they can
be stored in a database for later retrieval. Most often, you'll use a relational database, an
object oriented database, or a hybrid object/relational database for persistent storage. The
UML is well suited to modeling logical database schemas, as well as physical databases
themselves.
The UML's class diagrams are a superset of entity-relationship (E-R) diagrams, a common
modeling tool for logical database design. Whereas classical E-R diagrams focus only on
data, class diagrams go a step further by permitting the modeling of behavior, as well. In
the physical database, these logical operations are generally turned into triggers or stored
procedures.
To model a schema,
 Identify those classes in your model whose state must transcend the lifetime of their
applications.
 Create a class diagram that contains these classes and mark them as persistent (a standard
tagged value). You can define your own set of tagged values to address database-specific
details.
 Expand the structural details of these classes. In general, this means specifying the details
of their attributes and focusing on the associations and their cardinalities that structure
these classes.
 Watch for common patterns that complicate physical database design, such as cyclic
associations, one-to-one associations, and n-ary associations. Where necessary, create
intermediate abstractions to simplify your logical structure.
 Consider also the behavior of these classes by expanding operations that are important for
data access and data integrity. In general, to provide a better separation of concerns,
business rules concerned with the manipulation of sets of these objects should be
encapsulated in a layer above these persistent classes.
 Where possible, use tools to help you transform your logical design into a physical design.
 Figure : Modeling a Schema

3. Forward and Reverse Engineering

Modeling is important, but you have to remember that the primary product of a
development team is software, not diagrams. Of course, the reason you create models is to
predictably deliver at the right time the right software that satisfies the evolving goals of its
users and the business. For this reason, it's important that the models you create and the
implementations you deploy map to one another and do so in a way that minimizes or even
eliminates the cost of keeping your models and your implementation in sync with one
another.
Forward engineering is the process of transforming a model into code through a mapping
to an implementation language. Forward engineering results in a loss of information,
because models written in the UML are semantically richer than any current object-
oriented programming language. In fact, this is a major reason why you need models in
addition to code. Structural features, such as collaborations, and behavioral features, such
as interactions, can be visualized clearly in the UML, but not so clearly from raw code.
To forward engineer a class diagram,
 Identify the rules for mapping to your implementation language or languages of choice.
This is something you'll want to do for your project or your organization as a whole.
 Depending on the semantics of the languages you choose, you may have to constrain your
use of certain UML features. For example, the UML permits you to model multiple
inheritance, but Smalltalk permits only single inheritance. You can either choose to
prohibit developers from modeling with multiple inheritance (which makes your models
language- dependent) or develop idioms that transform these richer features into the
implementation language (which makes the mapping more complex).
 Use tagged values to specify your target language. You can do this at the level of
individual classes if you need precise control. You can also do so at a higher level, such as
with collaborations or packages.
 Use tools to forward engineer your models.
 Figure - Forward Engineering

Reverse engineering is the process of transforming code into a model through a mapping
from a specific implementation language. Reverse engineering results in a flood of
information, some of which is at a lower level of detail than you'll need to build useful
models. At the same time, reverse engineering is incomplete. There is a loss of information
when forward engineering models into code, and so you can't completely recreate a model
from code unless your tools encode information in the source comments that goes beyond
the semantics of the implementation language.
To reverse engineer a class diagram,

 Identify the rules for mapping from your implementation language or languages of choice.
This is something you'll want to do for your project or your organization as a whole.
 Using a tool, point to the code you'd like to reverse engineer. Use your tool to generate a
new model or modify an existing one that was previously forward engineered.
 Using your tool, create a class diagram by querying the model. For example, you might
start with one or more classes, then expand the diagram by following specific relationships
or other neighboring classes. Expose or hide details of the contents of this class diagram as
necessary to communicate your intent.

6. Object Diagrams
Object diagrams model the instances of things contained in class diagrams. An object
diagram shows a set of objects and their relationships at a point in time.
You use object diagrams to model the static design view or static process view of a system.
This involves modeling a snapshot of the system at a moment in time and rendering a set of
objects, their state, and their relationships.

An object diagram, therefore, expresses the static part of an interaction, consisting of the
objects that collaborate, but without any of the messages passed among them. In both
cases, an object diagram freezes a moment in time, as in Figure
 Figure An Object Diagram

Terms and Concepts

An object diagram is a diagram that shows a set of objects and their relationships at a point
in time. Graphically, an object diagram is a collection of vertices and arcs
Contents
Object diagrams commonly contain
 Objects
 Links

Common Uses
You use object diagrams to model the static design view or static process view of a system
just as you do with class diagrams, but from the perspective of real or prototypical
instances. This view primarily supports the functional requirements of a system• that is, the
services the system should provide to its end users. Object diagrams let you model static
data structures.
When you model the static design view or static process view of a system, you typically
use object diagrams in one way:
· To model object structures

CommonModeling
Techniques
1.
Modeling Object Structures
When you construct a class diagram, a component diagram, or a deployment diagram, what
you are really doing is capturing a set of abstractions that are interesting to you as a group
and, in that context, exposing their semantics and their relationships to other abstractions
in the group.
To model an object structure,
 Identify the mechanism you'd like to model. A mechanism represents some function or
behavior of the part of the system you are modeling that results from the interaction of a
 society of classes, interfaces, and other things.

 For each mechanism, identify the classes, interfaces, and other elements that participate in
this collaboration; identify the relationships among these things, as well.
 Consider one scenario that walks through this mechanism. Freeze that scenario at a
moment in time, and render each object that participates in the mechanism.
 Expose the state and attribute values of each such object, as necessary, to understand the
scenario.
 Similarly, expose the links among these objects, representing instances of associations
among them.

For example, Figure shows a set of objects drawn from the implementation of an
autonomous robot. This figure focuses on some of the objects involved in the mechanism
used by the robot to calculate a model of the world in which it moves.

Figure 14-2 Modeling Object Structures

[Link] and Reverse Engineering

Forward engineering (the creation of code from a model) an object diagram is theoretically
possible but pragmatically of limited value. In an object-oriented system, instances are
things that are created and destroyed by the application during run time. Therefore, you
can't exactly instantiate these objects from the outside.
 To reverse engineer an object diagram,
 Chose the target you want to reverse engineer. Typically, you'll set your context inside an
operation or relative to an instance of one particular class.
 Using a tool or simply walking through a scenario, stop execution at a certain moment in
time.
 Identify the set of interesting objects that collaborate in that context and render them in an
object diagram.
 As necessary to understand their semantics, expose these object's states.
 As necessary to understand their semantics, identify the links that exist among these
objects.
 If your diagram ends up overly complicated, prune it by eliminating objects that are not
germane to the questions about the scenario you need answered. If your diagram is too
simplistic, expand the neighbors of certain interesting objects and expose each object's state
more deeply.

7. Interaction Diagrams
Sequence diagrams and collaboration diagrams
 both of which are called interaction diagrams
 are two of the five diagrams used in the UML for modeling the dynamic aspects of
systems.
An interaction diagram shows an interaction, consisting of a set of objects and their
relationships, including the messages that may be dispatched among them. A sequence
diagram is an interaction diagram that emphasizes the time ordering of messages; a
collaboration diagram is an interaction diagram that emphasizes the structural organization
of the objects that send and receive messages.

Terms and Concepts

An interaction diagram shows an interaction, consisting of a set of objects and their
relationships, including the messages that may be dispatched among them. A sequence
diagram is an interaction diagram that emphasizes the time ordering of messages.
Graphically, a sequence diagram is a table that shows objects arranged along the X axis and
messages, ordered in increasing time, along the Y axis. A collaboration diagram is an
interaction diagram that emphasizes the structural organization of the objects that send and
receive messages. Graphically, a collaboration diagram is a collection of vertices and arcs.

Contents
Interaction diagrams commonly contain
 Objects
 Links
 Message
A. Sequence Diagrams
A sequence diagram emphasizes the time ordering of messages. As Figure shows, you
form a sequence diagram by first placing the objects that participate in the interaction at the
top of your diagram, across the X axis. Typically, you place the object that initiates the
interaction at the left, and increasingly more subordinate objects to the right. Next, you
place the messages that these objects send and receive along the Y axis, in order of
increasing time from top to bottom. This gives the reader a clear visual cue to the flow of
control over time.
Figure Sequence Diagram

Sequence diagrams have two features that distinguish them from collaboration diagrams.

You can specify the vitality of an object or a link by marking it with a new destroyed, or
transient constraint
First, there is the object lifeline. An object lifeline is the vertical dashed line that
represents the existence of an object over a period of time.
Second, there is the focus of control. The focus of control is a tall, thin rectangle that
shows the period of time during which an object is performing an action, either directly or
through a subordinate procedure
B. Collaboration Diagrams
A collaboration diagram emphasizes the organization of the objects that participate in an
interaction.
Collaboration diagrams have two features that distinguish them from sequence diagrams.
First, there is the path. To indicate how one object is linked to another, you can attach a
path stereotype to the far end of a link (such as »localᑺ, indicating that the designated
object is local to the sender).
Second, there is the sequence number. To indicate the time order of a message, you prefix
the message with a number (starting with the message numbered 1), increasing
monotonically for each new message in the flow of control (2, 3, and so on). To show
nesting, you use Dewey decimal numbering (1 is the first message; 1.1 is the first message
nested in message 1; 1.2 is the second message nested in message 1; and so on). You can
show nesting to an arbitrary depth. Note also that, along the same link, you can show many
messages (possibly being sent from different directions), and each will have a unique
sequence number.

As Figure shows, you form a collaboration diagram by first placing the objects that
participate in the interaction as the vertices in a graph. Next, you render the links that
connect these objects as the arcs of this graph. Finally, you adorn these links with the
messages that objects send and receive. This gives the reader a clear visual cue to the flow
of control in the context of the structural organization of objects that collaborate.
Figure Collaboration Diagram

Semantic Equivalence
Because they both derive from the same information in the UML's metamodel, sequence
diagrams and collaboration diagrams are semantically equivalent. As a result, you can take a
 diagram in one form and convert it to the other without any loss of information, as you can
see in the previous two figures, which are semantically equivalent. However, this does not
mean that both diagrams will explicitly visualize the same information. For example, in the
previous two figures, the collaboration diagram shows how the objects are linked (note the
»localᑺ and »globalᑺ stereotypes), whereas the corresponding sequence diagram does not.
Similarly, the sequence diagram shows message return (note the return value committed),
but the corresponding collaboration diagram does not. In both cases, the two diagrams
share the same underlying model, but each may render some things the other does not.

Common Uses
You use interaction diagrams to model the dynamic aspects of a system. These dynamic
aspects may involve the interaction of any kind of instance in any view of a system's
architecture, including instances of classes (including active classes), interfaces,
components, and nodes.
When you model the dynamic aspects of a system, you typically use interaction diagrams
in two ways.
1. To model flows of control by time ordering
Here you'll use sequence diagrams. Modeling a flow of control by time ordering
emphasizes the passing of messages as they unfold over time, which is a particularly useful
way to visualize dynamic behaviour in the context of a use case scenario. Sequence
diagrams do a better job of visualizing simple iteration and branching than do collaboration
diagrams.
2. To model flows of control by organization
Here you'll use collaboration diagrams. Modeling a flow of control by organization
emphasizes the structural relationships among the instances in the interaction, along which
messages may be passed. Collaboration diagrams do a better job of visualizing complex
iteration and branching and of visualizing multiple concurrent flows of control than do
sequence diagrams.

Common Modeling Techniques

[Link] Flows of Control by Time Ordering

Consider the objects that live in the context of a system, subsystem, operation or class.
Consider also the objects and roles that participate in a use case or collaboration. To model
a flow of control that winds through these objects and roles, you use an interaction
diagram; to emphasize the passing of messages as they unfold over time, you use a
sequence diagram, a kind of interaction diagram.
To model a flow of control by time ordering,
 Set the context for the interaction, whether it is a system, subsystem, operation, or class, or
one scenario of a use case or collaboration.
 Set the stage for the interaction by identifying which objects play a role in the interaction.
Lay them out on the sequence diagram from left to right, placing the more important
objects to the left and their neighboring objects to the right.
 Set the lifeline for each object. In most cases, objects will persist through the entire
interaction. For those objects that are created and destroyed during the interaction, set their
lifelines, as appropriate, and explicitly indicate their birth and death with appropriately
stereotyped messages.
 Starting with the message that initiates this interaction, lay out each subsequent message
from top to bottom between the lifelines, showing each message's properties (such as its
parameters), as necessary to explain the semantics of the interaction.
 If you need to visualize the nesting of messages or the points in time when actual
computation is taking place, adorn each object's lifeline with its focus of control.
 If you need to specify time or space constraints, adorn each message with a timing mark
and attach suitable time or space constraints.
 If you need to specify this flow of control more formally, attach pre- and postconditions to
each message.

[Link] Flows of Control by Organization

Consider the objects that live in the context of a system, subsystem, operation, or class.
Consider also the objects and roles that participate in a use case or collaboration. To model
a flow of control that winds through these objects and roles, you use an interaction
diagram; to show the passing of messages in the context of that structure, you use a
collaboration diagram, a kind of interaction diagram.
To model a flow of control by organization,
 Set the context for the interaction, whether it is a system, subsystem, operation, or class, or
one scenario of a use case or collaboration.
 Set the stage for the interaction by identifying which objects play a role in the interaction.
Lay them out on the collaboration diagram as vertices in a graph, placing the more
important objects in the center of the diagram and their neighboring objects to the outside.
 Set the initial properties of each of these objects. If the attribute values, tagged values,
state, or role of any object changes in significant ways over the duration of the interaction,
place a duplicate object on the diagram, update it with these new values, and connect them
by a message stereotyped as become or copy (with a suitable sequence number).
 Specify the links among these objects, along which messages may pass.
1. Lay out the association links first; these are the most important ones, because they
represent structural connections.
2. Lay out other links next, and adorn them with suitable path stereotypes (such as
global and local) to explicitly specify how these objects are related to one another.
 Starting with the message that initiates this interaction, attach each subsequent message to
the appropriate link, setting its sequence number, as appropriate. Show nesting by using
Dewey decimal numbering.
 If you need to specify time or space constraints, adorn each message with a timing mark
and attach suitable time or space constraints.
 If you need to specify this flow of control more formally, attach pre- and postconditions to
each message.

3. Forward and Reverse Engineering

Forward engineering (the creation of code from a model) is possible for both sequence and
collaboration diagrams, especially if the context of the diagram is an operation

Reverse engineering (the creation of a model from code) is also possible for both sequence
and collaboration diagrams, especially if the context of the code is the body of an
operation. Segments of the previous diagram could have been produced by a tool from a
prototypical execution of the register operation.

Forward engineering is straightforward; reverse engineering is hard.