UNIT-2

OOAD

Importance Of Modeling:
There are many elements that contribute to successful software. Software organization
one common thread is the use of modeling.

Modeling is proven and well accepted engineering technique. We build architectural

models of houses to help their users visualize the final product. We also build the
models in the fields of sociology, economics, business management, automobiles and
new electrical devices.

“Model is a simplification of Reality:”

A Model provides the blue prints of a system. Model may encompass detailed plans.
Every system may described from different aspects using different models, and each
model is therefore a semantically closed abstraction of the system.

A model may be structural, emphasizing the organization of the system, (or) it

may be behavioral, emphasizing the dynamics of the system.

“We build models so that we can better understand the system we are developing”

We achieve 4 aims through the modeling, when are

1. Models help us to visualize the system

2. Models permit us to specify the structure (or) behavior at a system
3. Model gives us a template that guides us in constructing the system.
4. Model document the decision we have made.

“We build models of complex systems because we cannot comprehend such a

system in its entirety”

Through modeling, we narrow the problem we are studying by focusing on only one
aspect at a time. This is essentially the approach of "divide-and-conquer" , Attack a hard
problem by dividing it into a series of smaller problems that you can solve.
Principles of modeling:
There are 4 basic principles of modeling.

i) “The choice of what models to create has a profound influence on how a

problem is attacked and how a solution is shaped.”

In other words, choose your models well. The right models will brilliantly
illuminate the development problems. The wrong models will mislead you.
In software the models you choose can greatly affect your world view. If you
build a system through the eyes of a data base developer, you will likely focus on entity
relationship models

If you build a system through the eyes of object oriented developer, you will focus on
architecture, is centered on the classes and patterns of their interaction.

ii) “Every model may be expressed at different levels of precision.”

In any case the best kinds of models are those that let you choose your degree of
detail, depending on “WHO” is doing the viewing and why they need to view it.
An analyst “(or) end user will want to focus on issues of what. A developer will want
to focus on issues of” HOW”.

iii)“ The best models are connected to reality”.

It is best to have models that have a clear connection to reality and where
connection is weak, to know exactly how those models are divorced from the real world,
all models simplify reality.

iv) “No single model is sufficient. Every non trivial system is best approached
through a small set of nearly independent models.”

If you are constructing a building, there is no single set of blueprints that reveal
all its details. At the very least, you'll need floor plans, elevations, electrical plans,
heating plans, and plumbing plans. The operative phrase here is "nearly independent."
In this context, it means having models that can be built and studied separately but that
are still interrelated. To understand the architecture of object oriented software systems,
you need several complementary and inter locking views.
Object oriented modeling:
In software, there are several ways to approach a model. The two common ways
are from an ‘algorithmic perspective’ and from ‘object oriented perspective’.

The traditional view of software development takes an algorithmic perspective. In this

approach, the main building block of all software is the procedure (or) function. This
view leads developers to focus on issues to control and the decomposition of algorithms
into smaller ones.
As requirements change and the system grows, system built with an algorithmic focus
turn out to be very hard to maintain.

The contemporary views of software development take and object oriented

perspective. In this approach, the main building block of software system is the object
(or) class, an object is a thing. A class is a description of a set of common objects. Every
object has identity, state, and behavior for example, in the data base you will found
concrete objects, such as tables representing entities from problem domain.

Unified modeling language (UML):

The UML is a language for visualizing. Specifying, constructing and documenting the
artifacts of a software intensive system.

A conceptual model of the UML:

To understand the UML, you need to form a conceptual model of the language, and
this requires learning three major elements: the UML's basic building blocks, the
rules and some common mechanisms

Building blocks of the UML:

The vocabulary of the UML encompasses 3 kinds of building blocks

1. Things
2. Relationships
3. Diagrams

‘Things’ are the abstractors that are first class citizens in models.
‘Relationships’ tie these things together.
‘Diagrams’ group intersecting collections of things.

Things:

There are 4 kinds of things in the UML

1. Structural things
2. Behavioral things
3. Grouping things
4. An notational things

1. Structural things:

Structural things are nouns of UML models these are mostly static parts of a
model. There are 7 kinds of structural things.
i) Class:
Class is a description of a set of objects that share the same attributes, operations,
relationships and semantics. It implements one (or) more interfaces. Graphically a class
is rendered as a rectangle, usually including its name, attributes and operations.

ii) Interface:

An interface is a collection of operations that specify a service of a class (or)

component. An interface might represent the complete behavior of a class (or)
component (or)only a part of behavior. Graphically it is rendered as a circle together
with its name.
iii) Collaboration:

It defines an interaction and is a society of roles and other element that work
together to provide some cooperative behavior. A given class might participate in
several collaborations. Graphically a collaboration is rendered as an ellipse with solid
line including its name.

iv) Use case:

Use case is a description at set of sequence of actions that a system performs that
yields an observable result of value to a particular actor. A use case is realized by
collaboration. Graphically a usecase is rendered as an ellipse with solid line, including
its name.

v) Active class:

An active class is a class whose objects own one (or) more processes (or) threads
and therefore can initiate control activity. Graphically it is rendered just like a class but
with heavy lines, including its name, attributes and operations.
vi) Component:

A component is a physical and replaceable part of a system that conforms to

and provides the realization of a set of interfaces. In a system, you'll encounter
different kinds of deployment components Java Beans, as well as source code
files.Graphically it is represented as a rectangle with tabs including its name.

vii) Node:

Node is a physical element that exists at runtime and represents a computational

resource, generally having at least some memory and often processing capability set of
components may reside on a node and may also migrate from node to node. Graphically
a node is rendered as a cube, including its name.
2. Behavioral things:

Behavioral things are the dynamic parts of UML models representing over time
and space. There are 2 primary kinds of behavioral things.

i) Interaction:

Interaction is a behavior that comprises a set of massages exchanged among set

of objects with in a particular context to accomplish a specific purpose. Graphically a
message is rendered as a directed line almost always including the name of its
operations.

ii) State machine:

A state machine is a behavior that specifies the sequences of states an object (or) an
interaction goes through during its life time in response to events together with its
response to those events. Graphically a state is rendered as a rounded rectangle,
including its name

3.Grouping things:

Graphing things are the organizational parts of UML models. The primary kind of
graphing thing is packages.

i)package:

It is a general purpose mechanism for organizing elements into groups.

Structural things, behavioral thing and even other things may be placed in a package.
Graphically a package is rendered as a tabbed folder including its name and
sometimesit’s’ contents.

4.An notational things:

Annotational things are the explanatory parts of UML models. These are the
comments you may apply to describe.

i)NOTE:

A Note is simply a symbol for rendering constraints and comments attached ot an

element (or) a collection of elements.

Relationships:

There are 4 kinds of relationships in the UML

i) Dependency
ii) Association
iii) Generalization
iv) Realization
i) Dependency:

It is a semantic relationship between two things in which a change to one thing may
affect the semantics of the other thing. Graphically it is rendered as a dashed line
possibly directed and including a label.

ii) Association:

It is a structure relationship that describes a set of links, a link being a connection among
objects. Graphically an association is rendered as a solid line, possibly directed,
including its, name, and containing multiplicity and role name.

iii) Generalization:

it is a specialization / generalization relationship in which objects of the specialized

element (child) are substitutable for objects of the generalized element (parent) the child
shares the structure and the behavior of the parent. Graphically it is rendered as solid
line with narrow arrow head painting to parent.

IV) Realization:

It is a semantic relationship between classifiers, where in one classifier serapes a

contract that another classifier guarantees to carryout it is used in between interfaces
and the class (or) graphically it is rendered as a cross between a generalization and
dependency.
Diagrams:

A diagram is the graphical presentation of a set of elements, most often rendered as a

connected graph of vertices (things) and Ares (relations ships). UML include 9 such
diagrams.

1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. State chart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram

1. class diagram:

It shows a set of classes, interfaces and collaborations and their relationships. Class
diagram address the static design view of a system.

2.Object diagram:

It shows a set of objects and their relationships .this diagram address the static design
view of a system.

3.Use case diagram:

It shows a set of use cases and actors and their relationships. It address the static use
case view of a system.

4. Sequence diagram:

It is an interaction diagram that emphasizes the time ordering of messages. It consist

set of objects and relationships. It addresses the dynamic view of the system.
5.Collaboration diagram:

It is also an interaction diagram that emphasizes the structural organization of the

objects that send and receive in messages. It addresses the dynamic view of the system.

6.State chart diagram:

It shows a state machine consisting of states, transitions, events, and activities. It

address the dynamic view of a system

7.Activity diagram:

It is a special kind of state chart diagram that shows the flow from activity to activity
within a system. It addresses the dynamic view of a system.

8.component diagram:

It shows the organizations and dependencies among a set of components. It addresses

the static implementation view of a system.

9.Deployment Diagram:

It shows the configuration of run time processing hoes and the component that live on
them. It addresses the static deployment view of architecture.

Rules of the UML:

Like any language, the UML has a number of rules that specify what a well-formed
model should look like.
A well-formed model is one that is semantically self-consistent and in harmony with
all its relatedmodels.
The UML has semantic rules for

Names-What you can call things, relationships, and diagrams

Scope -The context that gives specific meaning to a name
Visibility-How those names can be seen and used by others
Integrity -How things properly and consistently relate to one another
Execution-What it means to run or simulate a dynamic model
Models built during the development of a software-intensive system tend to evolve and
may be viewed by many stakeholders in different ways and at different times. For this
reason, it is common for the development team to not only build models that are well-
formed, but also to build models that are

Elided -Certain elements are hidden to simplify the view

Incomplete -Certain elements may be missing
Inconsistent -The integrity of the model is not guaranteed

Common mechanisms in the UML:

There 4 common mechanisms in the UML

1. Specifications
2. Adornments
3. Common divisions
4. Extensibility mechanisms

1. Specifications:

UML is more than just a graphical language. Rather specification that provides a
textual statements of the syntax and semantics of that building block.
For ex: behind a class icon is a specification that provides the full set of attributes,
operations,

2. Adornments:

A class’s specification may include other details such as whether it is abstract (or) the
visibility of its attributes and operations. A many of these details can be rendered as
graphical (or) textual adornments to the class basic rectangular notation
For ex: the bellow fig shows a class, adorned to indicated that is an abstract class with
two public one protected and one private operation.
 3. Common divisions:

In modelingObject oriented systems; the world often gets divided in at least a couple
of ways.
First, there is the division of class and object. A class is an abstraction. An object is
one concrete manifestation of that abstraction.

In above figure, there is one class named customer together with three objects
Jan(which is marked explicitly as being a Customer object), :Customer(an anonymous
Customerobject).
Second, there is a separation of interface and implementation.

In above fig, there is a one component named ‘spelling wizard.dll’ that implements
two interfaces I unknown and I spelling.
4. Extensibility mechanisms:

The UML’S extensibility mechanisms include

• Stereotypes
• Tagged values
• Constraints

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, In java (or) c++ the exceptions are modeled as special classes. It is marked
with overflow stereotyped.

Tagged value:

A tagged value extends the properties of a UML building block, allowing you create
new information in that element’s specification. For example. The class ‘Event queue’
is extended by marking its version and author explicitly.

Constraint:

It extends the semantics of UML building blocks, allowing you to add new rules (or)
modify for example:
In ‘Event Queue’ class all addition are done in ‘order’

Architecture:
Architecture is the set of significant decision about
• The organization of a software system
 • The selection of the structural elements and their interfaces by which the system
is composed.
• Their behavior, as specified in the collaborations among those elements.
• The composition of these structural and behavioural elements into progressively
larger subsystems
• The architectural style that guides this organization; the static and dynamic
elements and their interfaces, collaborations and their composition.

The bellow fig illustrates, the architecture of a software intensive system can best be
described by five interlocking views.

The use case view Of a system encompasses the use cases that describes the behavior
of the system as seen by its end users, analysts and testers. The static aspects of this
view are captured in use case diagrams, the dynamic aspects of this view are captured
in interaction diagrams.

The design view Of a system encompasses the classes, interfaces and collaborations
that form the vocabulary of the problem and its solution. Which supports the functional
requirements of a system. The static and dynamic aspects of this view is captured in
class, object and interaction diagrams respectively.

The process view Of the system encompasses the threads and processes that form the
system’s concurrency and synchronization mechanism. This view addresses the
performance, scalability and throughput of the system.
The static and dynamic aspects of this view is captured in class, object and interaction
diagrams respectively.

The implementation view Of a system encompasses the components and files that are
used to assemble and releases the physical system. This view addresses the
configuration management of the system releases. The static aspects of this view are
captures in component diagrams, the dynamic aspects of this view captured in
interaction diagrams.

The deployment view Of a system encompasses the nodes that form the system’s
hardware topology on which the system executes. This view addresses the distribution,
delivery and installation of the parts that make up the physical system. The static aspects
of this view are captured in deployment diagrams. The dynamic aspects of this view are
captured in interaction diagrams.

Software development life cycle:

In UML, you should consider a process that is

• Use case driven

• Architecture centric
• Interactive and incremental

Use case driven means that use cases are used as a primary artifact for establishingthe
desired behavior of the system, for verifying and validating the systems’ architecture.

Architecture- centric means that a system’s architecture is used as a primary and

evolving the system under development.

An iterative process is one that involves managing a stream of executable releases. An

incremental process is one that involves the continuous integration of the systems
architecture to produce these releases.
This use case driven, architecture – centric and iterative / incremental process can be
broken into phases.

A phase is the span of time between two major milestones of the process, when a well-
defined set of objectives are met, artifacts are completed and decisions are made.

The bellow fig shows, 4 phases in s/w development life cycle.

• Inception
• Elaboration
• Construction
• Transition
Inception is the first phase of the process the goals of inception phase are:

• Establish business case for the project

• Establish project scope and boundary conditions
• Outline one (or) more candidate architecture.
• Identify risks.
• Prepare a project schedule and cost estimate.
• Feasibility.

Elaboration is the second phase of the process, when the product vision and its
architecture are defined. In this phase, the system’s requirements are articulated,
prioritized and base lined.
Construction is the third phase During the construction phase, all remaining
components and application features are developed and integrated into the product,
and all features are thoroughly tested.
The outcome of the construction phase is a product ready to put in hands of its end-
users. At minimum, it consists of:

▪ The software product integrated on the adequate platforms.

▪ The user manuals.
▪ A description of the current release.

Transition is the fourth phase of the process, when the software is turned in to the hands
of the user community. For even during this phase, the system is continuously
improved, bugs are dictated and features that did not make an earlier release are added.

chapter– II Structural Modeling

Classes
• 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.

Graphical Representation of Class in UML

Terms and Concepts

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 path name is the class name prefixed by the name of the package in which
that class lives.
 Simple Name Path Name

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 thing you are modeling that is shared by all objects of that
class
• You can further specify an attribute by stating its class and possibly a default initial value

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.
• A class may have any number of operations or no operations at all
• Graphically, operations are listed in a compartment just below the class attributes
• You can specify an operation by stating its signature, covering the name, visibility, type, and default
value of all parameters and a return type

Organizing Attributes and Operations

When drawing a class, you don't have to show every attribute and every operation at once. 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.
Responsibilities

• A Responsibility is a contract or an obligation of a class

• When you model classes, a good starting point is to specify the responsibilities of the things in your
vocabulary.
• A class may have any number of responsibilities, although, in practice, every well-structured class has at
least one responsibility and at most just a handful.

• Graphically, responsibilities can be drawn in a separate compartment at the bottom of the class icon

Common Modeling Techniques

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.

• 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 type 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

In object-oriented modeling, there are three kinds of relationships that are most important:
Dependency
Generalization
Association

Dependency
A dependency is a using relationship that states that a change in specification of one thing may affect another
thing that uses it but not necessarily the reverse. Graphically dependency is rendered as a dashed directed
line, directed to the thing being depended on.

Most often, you will use dependencies in the context of classes to show that one class uses another class as
an argument in the signature of an operation. if the used class changes, the operation of the other class may
be affected, as well, because the used class may now present a different interface or behaviour.

Generalization

A generalization is a relationship between a general thing (called the super class or parent) and a more specific
kind of that thing (called the subclass or child). Generalization means that the child is substitutable for the
parent. A child inherits the properties of its parents, especially their attributes and operations. Generalization
is sometimes called an "is-a-kind-of" relationship.
Graphically generalization is rendered as a solid directed line with a large open arrowhead, pointing to the
parent.
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.
Graphically, an association is rendered as a solid line connecting the same or different classes.

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; The same
class can play the same or different roles in other associations.
An instance of an association is called a link.

Multiplicity

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.
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).
Aggregation

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

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.

This figure shows a dependency from CourseSchedule to Course, because Course is used in both the
add and remove operations of CourseSchedule.
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.

• 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 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 it helps 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
 Common Mechanisms
Note
A note is a graphical symbol for rendering constraints or comments attached to an element or a collection of
elements
Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or graphical
comment.
A note may contain any combination of text or graphics, you can put a live URL inside a note, or even link to
or embed another document.

Stereotypes

A stereotype is an extension of the vocabulary of the UML, allowing you to create new kinds of building
blocks similar to existing ones but specific to your problem.
Graphically, a stereotype is rendered as a name enclosed by guillemets and placed above the name of
another element
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.
• A tagged value is an extension of the properties of a UML element, allowing you to create new
information in that element's specification.
• Graphically, a tagged value is rendered as a string enclosed by brackets and placed below the name
of another element.

Constraints

• A constraint specifies conditions that must be held true for the model to be well-formed.
• A constraint is rendered as a string enclosed by brackets and placed near the associated element.
• Graphically, a constraint is rendered as a string enclosed by brackets and placed near the associated
element or connected to that element or elements by dependency relationships.

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.

Modeling New Building Blocks

• Make sure there's not already a way to express what you want by using basic UML. If you have a
common modelling problem, chances are there's already some standard stereotype that will do what
you want.

• If you're convinced there's no other way to express these semantics, identify the primitive thing in the
UML that's most like what you want to model and define a new stereotype for that thing.

• Specify the common properties and semantics that go beyond the basic element being stereotyped
by defining a set of tagged values and constraints for the stereotype.

• If you want these stereotype elements to have a distinctive visual cue, define a new icon for the
stereotype
Modeling New Properties

• First, make sure there's not already a way to express what you want by using basic UML. If you have
a common modeling problem, chances are that there's already some standard tagged value that will
do what you want.

• If you're convinced there's no other way to express these semantics, add this new property to an
individual element or a stereotype.

Modeling New Semantics

• First, make sure there's not already a way to express what you want by using basic UML. If you have
a common modeling problem, chances are that there's already some standard constraint that will do
what you want.

• If you're convinced there's no other way to express these semantics, write your new semantics as text
in a constraint and place it adjacent to the element to which it refers.

• If you need to specify your semantics more precisely and formally, write your new semantics using
OCL.

Diagrams

System
• A system is a collection of subsystems organized to accomplish a purpose and described by a set of
models, possibly from different viewpoints
SubSystem
• A subsystem is a grouping of elements, of which some constitute a specification of the behavior
offered by the other contained elements.

Model
• A model is a semantically closed abstraction of a system, meaning that it represents a complete and
self-consistent simplification of reality, created in order to better understand the system. In the
context of architecture
View
• view is a projection into the organization and structure of a system's model, focused on one aspect
of that system
Diagram
• A diagram is the graphical presentation of a set of elements, most often rendered as a connected
graph of vertices (things) and arcs (relationships).
• A diagram is just a graphical projection into the elements that make up a system.
Structural Diagrams
• The UML's four structural diagrams exist to visualize, specify, construct, and document the static
aspects of a system.
• The UML's structural diagrams are roughly organized around the major groups of things you'll find
when modeling a system.

o Class diagram : Classes, interfaces, and collaborations

o Object diagram : Objects
o Component diagram : Components
o Deployment diagram : Nodes

Class Diagram
• We use class diagrams to illustrate the static design view of a system.
• A class diagram shows a set of classes, interfaces, and collaborations and their relationships.
• Class diagrams that include active classes are used to address the static process view of a system.

Object Diagram

• Object diagrams address the static design view or static process view of a system
• 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.

Component Diagram
• We use component diagrams to illustrate the static implementation view of a system.
• A component diagram shows a set of components and their relationships.
• Component diagrams are related to class diagrams in that a component typically maps to one or
more classes, interfaces, or collaborations.

Deployment Diagram

• We use deployment diagrams to illustrate the static deployment view of an architecture.

• A deployment diagram shows a set of nodes and their relationships.
• Deployment diagrams are related to component diagrams in that a node typically encloses one or
more components.

Behavioral Diagrams

• The UML's five behavioral diagrams are used to visualize, specify, construct, and document the
dynamic aspects of a system.
• The UML's behavioral diagrams are roughly organized around the major ways you can model the
dynamics of a system.

Use case diagram : Organizes the behaviors of the system

Sequence diagram : Focused on the time ordering of messages
Collaboration diagram : Focused on the structural organization of objects that send and
 receive messages
Statechart diagram : Focused on the changing state of a system driven by
events
Activity diagram : Focused on the flow of control from activity to activity

Use Case Diagram

• A use case diagram shows a set of use cases and actors and their relationships.
• We 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

• We use sequence diagrams to illustrate the dynamic view of a system.

• A sequence diagram is an interaction diagram that emphasizes the time ordering of messages.
• A sequence diagram shows a set of objects and the messages sent and received by those objects.

Collaboration Diagram

• We use collaboration diagrams to illustrate the dynamic view of a system.

• A collaboration diagram is an interaction diagram that emphasizes the structural organization of the
objects that send and receive messages.
• A collaboration diagram shows a set of objects, links among those objects, and messages sent and
received by those objects.

* Sequence and collaboration diagrams are isomorphic, meaning that you can convert from one to the other
without loss of information.

Statechart Diagram

• We use statechart diagrams to illustrate the dynamic view of a system.

• They are especially important in modeling the behavior of an interface, class, or collaboration.
• A statechart diagram shows a state machine, consisting of states, transitions, events, and activities.

Activity Diagram

• We 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 among objects.
• An activity diagram shows the flow from activity to activity within a system.
• An activity shows a set of activities, the sequential or branching flow from activity to activity, and
objects that act and are acted upon.
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.

• For each of these views, decide which artifacts you need to create to capture the essential details of
that view.

• 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

• 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:

Building blocks and relationships:

• Hide those that are not relevant to the intent of your diagram or the needs of your reader.
Adornments:
• Reveal only the adornments of these building blocks and relationships that are essential to
understanding your intent.

Flow:
• In the context of behavioral diagrams, expand only those messages or transitions that are
essential to understanding your intent.
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:

Use cases and their realization:

Use cases in a use case model will trace to collaborations in a design model.
Collaborations and their realization:
Collaborations will trace to a society of classes that work together to carry out the collaboration.
Components and their design:
Components in an implementation model will trace to the elements in a design model.
Nodes and their components:
Nodes in a deployment model will trace to components in an implementation model.

Interaction Diagram at a High Level of Abstraction

 Interaction at a Low Level of Abstraction

* Both of these diagrams work against the same model, but at different levels of detail.

Modeling Complex Views

• First, convince yourself there's 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 an online version of the diagram brings, but you can step back from the diagram and
study it for common patterns.

- ****************