OOAD

UNIT - 2
Class
• A class is a description of a set of objects that share the same attributes, operations, relationships, and
semantics. Graphically, a class is rendered as a rectangle.
• Names
• Attributes
• Operations
• Responsibilities
Names
• 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 qualified name is the class name prefixed by the name of the package in
which that class lives.
Attributes
• 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.
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 that is shared by
all objects of that class. A class may have any number of operations or no operations at all.
Responsibilities
• 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.
Common Modeling
Techniques for Class

• Modeling the Vocabulary of a System

• Identify those things that users or
implementers use to describe the
problem or solution. Use CRC cards
and use case-based analysis to help
find these abstractions.
• For each abstraction, identify a set
of responsibilities. Make sure that
each class is crisply defined and that
there is a good balance of
responsibilities among all your
classes.
• Provide the attributes and operations
that are needed to carry out these
responsibilities for each class.
• Modeling the Distribution of
Responsibilities in a System
• Identify a set of classes that work
together closely to carry out some
behavior.
• Identify a set of responsibilities for each
of these classes.
• Look at this set of classes as a whole,
split classes that have too many
responsibilities into smaller abstractions,
collapse tiny classes that have trivial
responsibilities into larger ones, and
reallocate responsibilities so that each
abstraction reasonably stands on its own.
• Consider the ways in which those classes
collaborate with one another, and
redistribute their responsibilities
accordingly so that no class within a
collaboration does too much or too little.
• Modeling Nonsoftware Things
• Model the thing you are abstracting as a class.
• If you want to distinguish these things from the UML’s defined building blocks, create a new building block by using stereotypes to
specify these new semantics and to give a distinctive visual cue.
• If the thing you are modeling is some kind of hardware that itself contains software, consider modeling it as a kind of node as well, so
that you can further expand on its structure.
• Modeling Primitive Types
• Model the thing you are abstracting as a class or an enumeration, which is rendered using class notation with
the appropriate stereotype.
• If you need to specify the range of values associated with this type, use constraints.
RELATIONSHIPS
• Dependencies are using relationships. For example, pipes depend on the water heater to heat the water they
carry.
• Associations are structural relationships among instances. For example, rooms consist of walls and other
things; walls themselves may have embedded doors and windows; pipes may pass through walls.
• Generalizations connect generalized classes to more-specialized ones in what is known as subclass/superclass
or child/parent relationships. For example, a picture window is a kind of window with very large, fixed panes;
a patio window is a kind of window with panes that open side to side.
Dependencies
• A dependency is a relationship that states that one thing (for example, class Window) uses the information
and services of another thing (for example, class Event), but not necessarily the reverse. Graphically, a
dependency is rendered as a dashed directed line, directed to the thing being depended on. Choose
dependencies when you want to show one thing using another.
Generalizations
• A generalization is a relationship between a
general kind of thing (called the superclass or
parent) and a more specific kind of 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). An objects of the child class may be
used for a variable or parameter typed by the
parent, but not the reverse. In other words,
generalization means that the child is
substitutable for a declaration of the parent. A
child inherits the properties of its parents,
especially their attributes and operations.
Associations
• 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 relate objects of one class to objects of the
other class. 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.
• Name An association can have a name, and you use that name to describe the nature of the relationship.
• Role When a class participates in an association, it has a specific role that it plays in that relationship;
• 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. It represents a range of
integers specifying the possible size of the set of related objects. It is written as an expression with a
minimum and maximum value, which may be the same; two dots are used to separate the minimum and
maximum values.
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
Common Modeling
Techniques
• Modeling Simple Dependencies
• Create a dependency pointing from the class with the
operation to the class used as a parameter in the operation.
• Modeling Single Inheritance
• Given a set of classes, look for responsibilities, attributes,
and operations that are common to two or more classes.
• Elevate these common responsibilities, attributes, and
operations to a more general class. If necessary, create a
new class to which you can assign these elements (but be
careful about introducing too many levels).
• Specify that the more-specific classes inherit from the
more-general class by placing a generalization relationship
that is drawn from each specialized class to its more-
general parent.
• Modeling Structural Relationships
• For each pair of classes, if you need to navigate from objects
of one to objects of another, specify an association between
the two. This is a data-driven view of associations.
• For each pair of classes, if objects of one class need to
interact with objects of the other class other than as local
variables in a procedure or parameters to an operation,
specify an association between the two. This is more of a
behavior-driven view of associations.
• For each of these associations, specify a multiplicity
(especially when the multiplicity is not *, which is the
default), as well as role names (especially if they help to
explain the model).
• If one of the classes in an association is structurally or
organizationally a whole compared with the classes at the
other end that look like parts, mark this as an aggregation by
adorning the association at the end near the whole with a
diamond.
COMMON MECHANISMS
Notes
• A note that renders a comment has no semantic impact, meaning that its contents do not alter the meaning of
the model to which it is attached.
• Therefore, notes are used to specify things like requirements, observations, reviews, and explanations, in
addition to rendering constraints.
Stereotypes
• A stereotype is not the same as a parent class in a parent/child generalization relationship. Rather, you can
think of a stereotype as a metatype (a type that defines other types), because each one creates the equivalent
of a new class in the UML’s metamodel.
Tagged Values
• Every thing in the UML has its own set of properties: classes have names, attributes, and operations;
associations have names and two or more ends, each with its own properties; and so on. With stereotypes, you
can add new things to the UML; with tagged values, you can add new properties to a stereotype.
• You define tags that apply to individual stereotypes so that everything with that stereotype has that tagged
value. A tagged value is not the same as a class attribute. Rather, you can think of a tagged value as metadata
because its value applies to the element specification, not to its instances.
Constraints
• A constraint specifies conditions that a run-time configuration must satisfy to conform to the model.
• A constraint is rendered as a string enclosed by brackets and placed near the associated element. This notation
is also used as an adornment to the basic notation of an element to visualize parts of an element’s
specification that have no graphical cue.
Common Modeling
Techniques
• Modeling Comments
• Put your comment as text in a note and place it adjacent to
the element to which it refers. You can show a more explicit
relationship by connecting a note to its elements using a
dependency relationship.
• Remember that you can hide or make visible the elements of
your model as you see fit. This means that you don’t have to
make your comments visible everywhere the elements to
which it is attached are visible. Rather, expose your
comments in your diagrams only insofar as you need to
communicate that information in that context.
• If your comment is lengthy or involves something richer than
plain text, consider putting your comment in an external
document and linking or embedding that document in a note
attached to your model.
• As your model evolves, keep those comments that record
significant decisions that cannot be inferred from the model
itself, and—unless they are of historic interest—discard the
others.
• Modeling New Properties
• First, make sure there’s not already a way to express what you want by using basic UML.
• If you’re convinced there’s no other way to express these semantics, define a stereotype and add the new properties to the stereotype.
The rules of generalization apply—tagged values defined for one kind of stereotype apply to its children.
• Modeling New Semantics
• First, make sure there’s not already a way to express what you want by using basic UML.
• If you’re convinced there’s no other way to express these semantics, write your new semantics in a constraint placed near the element
to which it refers. You can show a more explicit relationship by connecting a constraint to its elements using a dependency
relationship.
• If you need to specify your semantics more precisely and formally, write your new semantics using OCL.
Diagrams
• Diagram is a graphical presentation of a set of elements, most often rendered as a connected graph of vertices
(things) and arcs (relationships). You use diagrams to visualize your system from different perspectives.
Because no complex system can be understood in its entirety from only one perspective, the UML defines
several diagrams so that you can focus on different aspects of your system independently.
• Good diagrams make the system you are developing understandable and approachable.
• Structural Diagrams
• Behavioral Diagrams
Structural Diagrams
• The UML’s structural diagrams exist to visualize, specify, construct, and document the static aspects of a
system. You can think of the static aspects of a system as representing its relatively stable skeleton and
scaffolding.
• The UML’s structural diagrams are roughly organized around the major groups of things you’ll find when
modeling a system.
1. Class diagram Classes, interfaces, and collaborations
2. Component diagram Components
3. Composite structure diagram Internal structure
4. Object diagram Objects
5. Artifact diagram Artifacts
6. Deployment diagram Nodes
• Class Diagram A class diagram shows a set of classes, interfaces, and collaborations and their
relationships. Class diagrams are the most common diagram found in modeling object-oriented systems. You
use class diagrams to illustrate the static design view of a system. Class diagrams that include active classes
are used to address the static process view of a system.
• Component Diagram An component diagram shows the internal parts, connectors, and ports that
implement a component. When the component is instantiated, copies of its internal parts are also instantiated.
• Composite Structure Diagram An composite structure diagram shows the internal structure of a
class or a collaboration. The difference between components and composite structure is small and this book
treats them both as component diagrams.
• Object Diagram An object diagram shows a set of objects and their relationships. You use object
diagrams to illustrate data structures, the static snapshots of instances of the things found in class diagrams.
Object diagrams address the static design view or static process view of a system just as class diagrams do,
but from the perspective of real or prototypical cases.
• Artifact Diagram An artifact diagram shows a set of artifacts and their relationships to other artifacts
and to the classes that they implement. You use artifact diagrams to show the physical implementation units
of the system. (UML considers artifacts to be part of deployment diagrams, but we separate them for
convenience of discussion.)
• Deployment Diagram A deployment diagram shows a set of nodes and their relationships. You use
deployment diagrams to illustrate the static deployment view of an architecture. Deployment diagrams are
related to component diagrams in that a node typically encloses one or more components.
Behavioral Diagrams
• The UML’s behavioral diagrams are used to visualize, specify, construct, and document the dynamic aspects
of a system. You can think of the dynamic aspects of a system as representing its changing parts.
• The UML’s behavioral diagrams are roughly organized around the major ways you can model the dynamics
of a system.
1. Use case diagram Organizes the behaviors of the system
2. Sequence diagram Focuses on the time ordering of messages
3. Communication diagram Focuses on the structural organization of objects that send and
receive messages
4. State diagram Focuses on the changing state of a systemdriven by events
5. Activity diagram Focuses on the flow of control from activity to activity
• Use Case Diagram A use case diagram shows a set of use cases and actors (a special kind of class) and
their relationships. You apply use case diagrams to illustrate the static use case view of a system. Use case
diagrams are especially important in organizing and modeling the behaviors of a system
• Sequence Diagram A sequence diagram is an interaction diagram that emphasizes the time ordering
of messages. A sequence diagram shows a set of roles and the messages sent and received by the instances
playing the roles. You use sequence diagrams to illustrate the dynamic view of a system.
• Communication Diagram A communication diagram is an interaction diagram that emphasizes the
structural organization of the objects that send and receive messages. A communication diagram shows a set
of roles, connectors among those roles, and messages sent and received by the instances playing the roles.
You use communication diagrams to illustrate the dynamic view of a system.
• State Diagram A state diagram shows a state machine, consisting of states, transitions, events, and
activities. You use state diagrams to illustrate the dynamic view of a system. They are especially important in
modeling the behavior of an interface, class, or collaboration. State diagrams emphasize the event-ordered
behavior of an object, which is especially useful in modeling reactive systems.
• Activity Diagram An activity diagram shows the flow from step to step within a computation. An
activity shows a set of actions, the sequential or branching flow from action to action, and values that are
produced or consumed by actions. You use activity diagrams to illustrate the dynamic view of a system.
Activity diagrams are especially important in modeling the function of a system. Activity diagrams
emphasize the flow of control within the execution of a behaviour.
Common Modeling Techniques
• Modeling Different Views of a System
• Decide which views you need to best express the architecture of your system and to expose the technical risks
to your project. The five views of an architecture described earlier are a good starting point.
• For each of these views, decide which artifacts you need to create to capture the essential details of that view.
For the most part, these artifacts will consist of various UML diagrams.
• As part of your process planning, decide which of these diagrams you’ll want to put under some sort of
formal or semi-formal control. These are the diagrams for which you’ll want to schedule reviews and to
preserve as documentation for the project.
• Allow room for diagrams that are thrown away. Such transitory diagrams are still useful for exploring the
implications of your decisions and for experimenting with changes.
Modeling Different Levels of Abstraction
To model a system at different levels of abstraction by presenting diagrams with different levels of detail,
• Consider the needs of your readers, and start with a given model.
• If your reader is using the model to construct an implementation, she’ll need diagrams that are at a lower
level of abstraction, which means that they’ll need to reveal a lot of detail. If she is using the model to present
a conceptual model to an end user, she’ll need diagrams that are at a higher level of abstraction, which means
that they’ll hide a lot of detail.
• Depending on where you land in this spectrum of low-to-high levels of abstraction, create a diagram at the
right level of abstraction by hiding or revealing the following four categories of things from your model:
1. Building blocks and relationships: Hide those that are not relevant to the intent of your diagram or the needs of your reader.
2. Adornments: Reveal only the adornments of these building blocks and relationships that are essential to understanding your intent.
3. Flow: In the context of behavioral diagrams, expand only those messages or transitions that are essential to understanding your
intent.
4. Stereotypes: In the context of stereotypes used to classify lists of things, such as attributes and operations, reveal only those
stereotyped items that are essential to understanding your intent.
To model a system at different levels of abstraction by creating models at different levels of abstraction,
• Consider the needs of your readers and decide on the level of abstraction that each should view, forming a
separate model for each level.
• In general, populate your models that are at a high level of abstraction with simple abstractions and your
models that are at a low level of abstraction with detailed abstractions. Establish trace dependencies among
the related elements of different models.
• In practice, if you follow the five views of an architecture, there are four common situations you’ll encounter
when modeling a system at different levels of abstraction:
1. Use cases and their realization: Use cases in a use case model will trace to collaborations in a design model.
2. Collaborations and their realization: Collaborations will trace to a society of classes that work together to carry out the
collaboration.
3. Components and their design: Components in an implementation model will trace to the elements in a design model.
4. Nodes and their components: Nodes in a deployment model will trace to components in an implementation model.
Modeling Complex Views
• First, convince yourself that there is no meaningful way to present this information at a higher level of
abstraction, perhaps eliding some parts of the diagram and retaining the detail in other parts.
• If you’ve hidden as much detail as you can and your diagram is still complex, consider grouping some of the
elements in packages or in higher-level collaborations, then render only those packages or collaborations in
your diagram.
• If your diagram is still complex, use notes and color as visual cues to draw the reader’s attention to the points
you want to make.
• If your diagram is still complex, print it in its entirety and hang it on a convenient large wall. You lose the
interactivity that an online version of the diagram brings, but you can step back from the diagram and study it
for common patterns.
CLASS DIAGRAMS
• Class diagrams commonly contain the following things:
• Classes
• Interfaces
• Dependency, generalization, and association relationships

• Common Uses
• To model the vocabulary of a system
• To model simple collaborations
• To model a logical database schema
Common Modeling
Techniques
Modeling Simple Collaborations
• 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.
Modeling a Logical Database Schema
• Identify those classes in your model whose state must
transcend the lifetime of their applications.
• Create a class diagram that contains these classes. You can
define your own set of stereotypes and 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 multiplicities that relate these
classes.
• Watch for common patterns that complicate physical database
design, such as cyclic associations and one-to-one
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.
Forward and Reverse Engineering
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 want 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 choose to prohibit developers from modeling with multiple inheritance (which
makes your models language- dependent), or you can develop idioms that transform these richer features into
the implementation language (which makes the mapping more complex).
• Use tagged values to guide implementation choices in 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 generate code.
• 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. It is unreasonable to expect to reverse
engineer a single concise model from a large body of code. You need to select portion of the code and build
the model from the bottom.
• 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.
• Manually add design information to the model to express the intent of the design that is missing or hidden in
the code.
ADVANCED
CLASSES
• Classifiers: A classifier is
a mechanism that describes
structural and behavioral
features. Classifiers include
classes, associations,
interfaces, datatypes, signals,
components, nodes, use cases,
and subsystems.
• Visibility: One of the design details you can specify for an attribute or operation is visibility. The
visibility of a feature specifies whether it can be used by other classifiers. In the UML, you can specify
any of four levels of visibility.
• Instance and Static Scope:Another important detail you can specify for a classifier’s attributes and
operations is scope. The scope of a feature specifies whether each instance of the classifier has its own
distinct value of the feature or whether there is just a single value of the feature shared by all instances of the
classifier.
• Multiplicity: The number of instances a class may have is called its multiplicity. Multiplicity is a
specification of the range of allowable cardinalities an entity may assume. In the UML, you can specify the
multiplicity of a class by writing a multiplicity expression in the upper-right corner of the class icon.
• Attributes:
• Operations:
• Template Classes: A template is a parameterized element. In such languages as C++ and Ada, you can
write template classes, each of which defines a family of classes. A template may include slots for classes,
objects, and values, and these slots serve as the template’s parameters. You can’t use a template directly; you
must instantiate it first. Instantiation involves binding these formal template parameters to actual ones.
• Standard Elements:
Common Modeling Techniques
Modeling the Semantics of a Class
• Specify the responsibilities of the class. A responsibility is a contract or obligation of a type or class and is rendered in a note attached
to the class, or in an extra compartment in the class icon.
• Specify the semantics of the class as a whole using structured text, rendered in a note (stereotyped as semantics) attached to the
class.
• Specify the body of each method using structured text or a programming language, rendered in a note attached to the operation by a
dependency relationship.
• Specify the pre- and postconditions of each operation, plus the invariants of the class as a whole, using structured text. These elements
are rendered in notes (stereotyped as precondition, postcondition, and invariant) attached to the operation or class by a
dependency relationship.
• Specify a state machine for the class. A state machine is a behavior that specifies the sequences of states an object goes through during
its lifetime in response to events, together with its responses to those events.
• Specify internal structure of the class.
• Specify a collaboration that represents the class. A collaboration is a society of roles and other elements that work together to provide
some cooperative behavior that’s bigger than the sum of all the elements. A collaboration has a structural part as well as a dynamic part,
so you can use collaborations to specify all dimensions of a class’s semantics.
• Specify the pre- and postconditions of each operation, plus the invariants of the class as a whole, using a formal language such as OCL.
ADVANCED RELATIONSHIPS
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.
Dependencies
• A dependency is a using relationship, specifying that a change in the specification of one thing may affect
another thing that uses it , but not the reverse. Graphically, a dependency is rendered as a dashed line,
directed to the thing that is depended on. Apply dependencies when you want to show one thing using
another.
• First, there are 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. permit 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. Ordinarily shown using text notation in the
form source : Target
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 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
• There are two stereotypes that apply to dependency relationships among packages.
1. import Specifies that the public contents of the target package enter the public namespace of the source, as if they had been
declared in the source.
2. access Specifies that the public contents of the target package enter the private namespace of the source. The unqualified names
may be used within the source, but they may not be re-exported.
• 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
• One stereotype you’ll encounter in the context of interactions among objects is
1. send Specifies that the source class sends the target event.
• one stereotype that you’ll encounter in the context of organizing the elements of your system into subsystems
and models is.
1. trace Specifies that the target is a historical predecessor of the source from an earlier stage of development
Generalizations
• A generalization is a relationship between a general classifier (called the superclass or parent) and a more
specific classifier (called the subclass or child).
• The UML defines four constraints that may be applied to generalization relationships:
1. complete Specifies that all children in the generalization have been specified in the model (although some may be elided in the
diagram) and that no additional children are permitted
2. incomplete Specifies that not all children in the generalization have been specified (even if some are elided) 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. For example, class Person
can be specialized into disjoint classes Man and Woman.
4. overlapping Specifies that objects of the parent may have more than one of the children as a type. For example, class
Vehicle can be specialized into overlapping subclasses LandVehicle and WaterVehicle (an amphibious vehicle is both).
Associations
• An association is a structural relationship, specifying that objects of one thing are connected to objects of
another.
• For example, a Library class might have a one-to-many association to a Book class, indicating that each
Book instance is owned by one Library instance. Furthermore, given a Book, you can find its owning
Library, and given a Library, you can navigate to all its Books. Graphically, an association is rendered
as a solid line connecting the same or different classes.
• You use associations when you want to show structural relationships.
• 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.
• For advanced uses, there are several other properties you can use to model subtle details, such as navigation,
qualification, and various flavours of aggregation.
Navigation
• Navigation Given a plain, unadorned association between two classes, such as Book and Library, it’s
possible to navigate from objects of one kind to objects of the other kind. Unless otherwise specified,
navigation across an association is bidirectional.
Visibility
• Visibility Given an association between two classes, objects of one class can see and navigate to objects of
the other unless otherwise restricted by an explicit statement of navigation.
Qualification
• Qualification In the context of an association, one of the most common modeling idioms you’ll
encounter is the problem of lookup. Given an object at one end of an association, how do you identify an
object or set of objects at the other end?
Composition
• Composition Aggregation turns out to be a simple concept with some fairly deep semantics. Simple
aggregation is entirely conceptual and does nothing more than distinguish a “whole” from a “part.” 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.
Association Classes
• Association Classes In an association between two classes, the association itself might have
properties. For example, in an employer/employee relationship between a Company and a Person, there is
a Job that represents the properties of that relationship that apply to exactly one pairing of the Person and
Company. It wouldn’t be appropriate to model this situation with a Company to Job association together
with a Job to Person association.
Constraints
• Constraints These simple and advanced properties of associations are sufficient for most of the structural
relationships you’ll encounter. However, if you want to specify a shade of meaning, the UML defines five
constraints that may b
1. ordered Specifies that the set of objects at one end of an association are in an explicit order. e applied to
association relationships.
2. set The objects are unique with no duplicates.
3. bag The objects are nonunique, may be duplicates.
4. ordered set The objects are unique but ordered.
5. list or sequence The objects are ordered, may be duplicates.
6. readonly A link, once added from an object on the opposite end of the association, may not be modified
or deleted. The default in the absence of this constraint is unlimited changeability.
Realizations
• A realization is a semantic relationship between classifiers in which one classifier specifies a contract that
another classifier guarantees to carry out. Graphically, a realization is rendered as a dashed directed line with
a large open arrowhead pointing to the classifier that specifies the contract.
• Realization is different enough from dependency, generalization, and association relationships that it is
treated as a separate kind of relationship. Semantically, realization is somewhat of a cross between
dependency and generalization, and its notation is a combination of the notation for dependency and
generalization.
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 (but not the
methods) applicable to the object.
• A role is the behavior of an entity participating in a particular context.
• Graphically, an interface may be rendered as a stereotyped class in order to expose its operations and other
properties. To show the relationship between a class and its interfaces, a special notation is provided.
• Provided interface (one that represents services provided by the class) is shown as a small circle attached to
the class box.
• Required interface (one that represents services required by a class of another class) is shown as a small
semicircle attached to the class box.
Names
• Every interface must have a name that distinguishes it from other interfaces. A name is a textual string. That
name alone is known as a simple name; a path name is the interface name prefixed by the name of the
package in which that interface lives.
Relationships
• Like a class, an interface may participate
in generalization, association, and
dependency relationships. In addition, an
interface may participate in realization
relationships. Realization is a semantic
relationship between two classifiers in
which one classifier specifies a contract
that another classifier guarantees to carry
out.
Operations
• An interface is a named collection of operations used to specify a service of a class or of a component. Unlike
classes or types, interfaces do not specify any implementation. Like a class, an interface may have any
number of operations. These operations may be adorned with visibility properties, concurrency properties,
stereotypes, tagged values, and constraints.
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 requires
from (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 postconditions for each operation, and use cases and state machines for the
interface as a whole.
Modeling Static and Dynamic Types
• Specify the different possible types of that object by rendering each type as a class (if the abstraction requires
structure and behavior) or as an interface (if the abstraction requires only behavior).
• Model all the roles the class of the object may take on at any point in time. You can mark them with the
«dynamic» stereotype. (This is not a predefined UML stereotype, but one that you can add.)
• In an interaction diagram, properly render each instance of the dynamically typed class. Display the type of
the instance in brackets below the object’s name, just like a state. (We are using UML syntax in a novel way,
but one that we feel is consistent with the intent of states.)
PACKAGES
• A package is a general-purpose mechanism for organizing the model itself into a hierarchy; it has no meaning
to the execution. Graphically, a package is rendered as a tabbed folder.
Names
• Every package must have a name that distinguishes it from other packages. A name is a textual string. That
name alone is known as a simple name; a qualified name is the package name prefixed by the name of the
package in which that package lives, if any. A double colon (::) separates package names.
Owned Elements
• A package may own other elements, including classes, interfaces, components, nodes, collaborations, use
cases, diagrams, and even other packages. Ownership is a composite relationship, which means that the
element is declared in the package. If the package is destroyed, the element is destroyed. Every element is
uniquely owned by exactly one package.
Visibility
• You can control the visibility of the elements owned by a package just as you can control the visibility of the
attributes and operations owned by a class. Typically, an element owned by a package is public, which means
that it is visible to the contents of any package that imports the element’s enclosing package.
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.
Modeling Architectural Views
• Identify the set of architectural views that are significant in the context of your problem. In practice, this
typically includes a design view, an interaction view, an implementation view, a deployment view, and a use
case view.
• Place the elements (and diagrams) that are necessary and sufficient to visualize, specify, construct, and
document the semantics of each view into the appropriate package.
• As necessary, further group these elements into their own packages.
 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.
• 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.
• An object diagram is a special kind of diagram and shares the same common properties as all other diagrams
—that is, a name and graphical contents that are a projection into a model. What distinguishes an object
diagram from all other kinds of diagrams is its content.
• Object diagrams commonly contain
• Objects
• Links

• Like all other diagrams, object diagrams may contain notes and constraints.
Common Modeling
Techniques
Modeling Object Structures
• 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.
• Create a collaboration to describe a mechanism.
• 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.
Reverse Engineering
• 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.
• You will usually have to manually add or label structure that is not explicit in the target code. The missing
information supplies the design intent that is only implicit in the final code.