UNIT - 1

Advanced Relationships
• Dependencies, generalizations, and associations are the
three most important relational building blocks of the
UML
• Using a fourth kind of relationship realization - you can
• model the connection between an interface and a class or
component, or between a use case and a collaboration.
• A relationship is a connection among things. In object-
oriented modeling, the four most important relationships
are dependencies, generalizations, associations, and
realizations.
• Graphically, a relationship is rendered as a path, with
different kinds of lines used to distinguish the different
relationships.
 Dependency
• A dependency is a using relationship,
specifying that a change in the specification of
one thing may affect another thing that uses,
but not necessarily the reverse.
• Graphically, a dependency is rendered as a
dashed line, directed to the thing that is
depended on.
• There are 17 such stereotypes, all of which can
be organized into six groups.
 First Group
• There are eight stereotypes that apply to dependency relationships among
classes and objects in class diagrams.
• 1. Bind - Specifies that the source instantiates the target template using the
given actual Parameters
• 2. derive - Specifies that the source may be computed from the target
• 3. friend - Specifies that the source is given special visibility into the target
• 4. instanceOf - Specifies that the source object is an instance of the target
classifier
• 5. instantiate - Specifies that the source creates instances of the target
• 6. Powertype - Specifies that the target is a powertype of the source; a
powertype is a classifier whose objects are all the children of a given parent
• 7. Refine - Specifies that the source is at a finer degree of abstraction than
the target
• 8. Use - Specifies that the semantics of the source element depends on the
semantics of the public part of the target
 Second Group
• There are two stereotypes that apply to dependency
relationships among packages
• 1. Access - Specifies that the source package is
granted the right to reference the elements of the
target package
• 2. Import - kind of access that specifies that the public
contents of the target package
 Third Group
• Two stereotypes apply to dependency relationships
among use cases
• 1. extend - Specifies that the target use case extends
the behavior of the source
• 2. Include - Specifies that the source use case
explicitly incorporates the behavior of another use
case at a location specified by the source
 Fourth Group
• Three stereotypes when modeling interactions
among objects
• 1. become - Specifies that the target is the same
object as the source but at a later point in time and
with possibly different values, state, or roles
• 2. call - Specifies that the source operation
invokes the target operation
• 3. copy - Specifies that the target object is an
exact, but independent, copy of the source
 Fifth Group
• One stereotype in the context of state machines
is
• send - Specifies that the source operation
sends the target event
 Sixth Group
• one stereotype in the context of organizing the
elements of your system into subsystems and
models
• Trace - Specifies that the target is an historical
ancestor of the source
 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).
• UML defines one stereotype and four
constraints that may be applied to
generalization relationships
• Stereotype.
• implementation - Specifies that the child
inherits the implementation of the parent but
does not make public nor support its interfaces
• Four standard constraints that apply to generalization
relationships
• 1. complete - Specifies that all children in the generalization
have been specified in the model and that no additional
children are permitted
• 2. incomplete - Specifies that not all children in the
generalization have been specified and that additional children
are permitted
• 3. disjoint - Specifies that objects of the parent may have no
more than one of the children as a type
• 4. overlapping –Specifies that objects of the parent may have
more than one of the children as a type
 Association
• An association is a structural relationship,
specifying that objects of one thing are
connected to objects of another.
• There are four basic adornments that apply to
an association: a name, the role at each end of
the association, the multiplicity at each end of
the association, and aggregation.
 Qualification
• You render a qualifier as a small rectangle
attached to the end of an association, placing
the attributes in the rectangle
 Composition
• Composition is a form of aggregation,
with strong ownership and coincident lifetime
as part of the whole.
 Association Classes
• This is a modeling element that has both
association and class properties.
 Realization
• A realization is a semantic relationship
between classifiers in which one classifier
specifies a contract that another classifier
guarantees to carry out.
 Common Modeling Techniques
Modeling Webs of Relationships
• Don't begin in isolation. Apply use cases and scenarios to drive your
discovery of the relationships among a set of abstractions.
• In general, start by modeling the structural relationships that are present.
These reflect the static view of the system and are therefore fairly tangible.
• Next, identify opportunities for generalization/specialization relationships;
use multiple inheritance sparingly.
• Only after completing the preceding steps should you look for
dependencies; they generally represent more-subtle forms of semantic
connection.
• For each kind of relationship, start with its basic form and apply advanced
features only as absolutely necessary to express your intent.
• Remember that it is both undesirable and unnecessary to model all
relationships among a set of abstractions in a single diagram or view.
Rather, build up your system's relationships by considering different views
on the system. Highlight interesting sets of relationships in individual
diagrams.
 Interfaces, Types, and Roles
• An interface is a collection of operations that
are used to specify a service of a class or a
component.
• A type is a stereotype of a class used to specify
a domain of objects, together with the
operations applicable to the object.
• A role is the behavior of an entity participating
in a particular context.
 Common Modeling Techniques
Modeling the Seams in a System
• Within the collection of classes and components in your system, draw a line
around those that tend to be tightly coupled relative to other sets of classes
and components.
• Refine your grouping by considering the impact of change. Classes or
components that tend to change together should be grouped together as
collaborations.
• Consider the operations and the signals that cross these boundaries, from
instances of one set of classes or components to instances of other sets of
classes and components.
• Package logically related sets of these operations and signals as interfaces.
• For each such collaboration in your system, identify the interfaces it relies
on (imports) and those it provides to others (exports). You model the
importing of interfaces by dependency relationships, and you model the
exporting of interfaces by realization relationships.
• For each such interface in your system, document its dynamics by using
pre- and post conditions for each operation, and use cases and state
machines for the interface as a whole.
 Packages
• A package is a general-purpose mechanism
for organizing elements into groups.
Graphically, a package is rendered as a tabbed
folder.
• A package name must be unique within its
enclosing package.
 Standard Elements
• The UML defines five standard stereotypes that apply
to packages.
• 1. facade - Specifies a package that is only a view on
some other package
• 2. framework - Specifies a package consisting mainly
of patterns
• 3. stub - Specifies a package that serves as a proxy for
the public contents of another package
• 4. subsystem - Specifies a package representing an
independent part of the entire system being modeled
• 5. system - Specifies a package representing the
entire system being modeled
 Common Modeling Techniques
Modeling Groups of Elements
• Scan the modeling elements in a particular architectural
view and look for clumps defined by elements that are
conceptually or semantically close to one another.
• Surround each of these clumps in a package.
• For each package, distinguish which elements should be
accessible outside the package. Mark them public, and
all others protected or private. When in doubt, hide the
element.
• Explicitly connect packages that build on others via
import dependencies.
• In the case of families of packages, connect specialized
packages to their more general part via generalizations.