Presented

by
N.Prathyush
a
 e s
s s
c l a
 Classes
contents:-
Ø Definition of the class
ØNames
ØAttributes
ØOperations
ØResponsibilities

Definition:-
A class is a description of a set of objects that share the same attributes, operations,
relationships, and semantics. A class is implemented one or more interfaces.
Graphically, a class is rendered as a rectangle. name

attributes

operations
Names:-
Every class must have a name that distinguishes it from other classes. A name is a
textual string with a simple path or path name which consists of the details of the packages of
class.
Customer Java::awt::Rectangle

simple names path names

Attributes:-
An attribute is a named property of a class that describes a range of values that
instances hold. An attribute represents some property of the thing you are modeling that is shared
by all objects of that class. Graphically, attributes are
walisted in a compartment just below the class
name.
Height: llfloat
Width: float
Thickness: float
IsLoadBearing : Boolean
= false
Operations:-
An operation is the implementation of a service that can be requested from any
object of a particular class. A may have any number of operations based on the responsibilities
mentioned the class. Graphically, the operations are listed in a compartment just below the
attributes.
Rectangl
e
add()
grow()
move()
Is Empty()

Operation by stating its signature, covering the name, type, and default value of all
parameters and a return type.
TemperatureSen
sor
Reset()
setAlarm(t :
Temperature)
Value() : Temperature
Responsibilities:-
A responsibility is a contract or an obligation of a class. When we create a
class, we make a statement that all the objects of that class should have the same kind of state
and the same kind of behavior. Graphically, responsibilities can be drawn in a separate
compartment at the bottom of the class.

FraudAgent

Responsibilities
--Determine the risk of
a customer order
--handle customer-
specific criteria for
fraud
Com mon Model ing Tec hni ques :-
A class is a structural thing which provides the abstraction of various properties
and operations shared by different objects, by using classes we can model the following.

Modeling to vocabulary of the system

Modeling the responsibilities of the system
Modeling non-software things
Modeling primitive types
Modeling to vocabulary of the system:-
Identify the things (nouns) that users or implements use to describe the
problem or solution.
For each thing identify a set of responsibilities that the class should
implement.
Provide the necessary attributes and operations that are needed to carryout
the above responsibilities.
Transaction
actions
Commit()
rollback()
wasSuccessf
ul()
Modeling the responsibilities of the system:-
Identify a set of classes that work together to carry out some behavior.
Identify a set of responsibilities for each of this classes.
Look at the set of classes as a whole, split the classes with more number of
responsibilities.
If the number of responsibilities are less rejoin the classes into generated the
classes and reallocate the responsibilities.

Model

Responsibilities
--manage the
state of the model
Modeling non-software things:-
Model the non-software thing as a class
If we want to distinguish the modeled class from the existing UML classes use a
stereo type.
If the non-software thing which we want to model is in hardware, try to model a
using a “ node “.
Accounts Receivable
Agent
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.
<<enumeration>
>
Boolean
False
true
 h i p
n s
t i o
el a s
R
Definition:-
A relationship is a connection among things. In UML a relationship is rendered as a path, with
different kinds of lines use to distinguish the kinds of relationships. In object-oriented modeling, the three
most important relationships.

Contents:-
Dependency
Generalization
Association

Dependency:-
A dependency is a “ using “ relationship that states that a change in specification of one thing
may effect another thing that uses it. Graphically, a dependency is rendered to the thing being depended on.

FilmClip
name
playOn(c :
-------------------> Channel
Channel)
Start()
Stop() --------
Reset()
dependenc
y
Generalization:-
A Generalization is a relationship between a general thing(super class) and a
more specific kind of that thing(sub class). Generalization is sometimes also known as IS-A-
KIND of relationship. Graphically, generalization is rendered as a solid directed line with a
large open arrow head, pointing to the parent.
Shape
origin base class

Move()
generalizatio Resize()
n Display()

Rectangl Circle Polygon

e
Corner: Radius : Points:
point float List
display

Square Leaf class

Association:-
An association is a structural relationship that specifies that the objects of one thing
are connected to objects of another. An association will be generally between two classes.
Graphically, an association is rendered as a solid line connection the same class or different
classes.
An association will generally in have the following four adornments
Name
Role Names
Multiplicity
Aggregation

Name:-
This is the name given for the relationship between two or more classes.

Name
name direction

Works for
Person Company

associatio
n
Role Names:-
These are the names given for the participating classes in a relationships. A
person playing the role of employee is associated with a company playing the role of
employer.
Person Company
employe employer
e association

Multiplicity:-
Multiplicity represent how many objects are involved across an instance of
association from the different classes. The stating of “ how many “ is known as Multiplicity.

1...
Person Company

associatio
n
Aggregation:-
If we want to model a” whole/part “ relationship in which one class to
represents a larger thing consisting of these smaller things, this kind of relationship is
often known as aggregation and implements strictly the relationship “ Has-A “.
An aggregation is a special kind of association rendered with an open or
hallow diamond at the end of “ whole “ class.

Company

aggregati
whole on

part Department
Common Modeling Techniques:-
using UML’s relationships we can model the following.
Modeling Simple Dependency
Modeling Single Inheritance
Modeling Structural relationships

Modeling Simple Dependency:-

The most common kind of dependency relationship is the connection between a
class that only uses another class as a parameter to an operation.
To model the “ using “ relationship.
Create a dependency pointing from the class with the operation to the class use as a
parameter in the operation.
CourseSchedule
----------------> Course
Add(c : Course)
Remove(c :
Course)

<<friend
>>

Iterator
Modeling Simple Inheritance:-
To model inheritance between a set of classes,
Identify the responsibilities, attributes and operations that are common to two or more
classes.
Create a class with the above mentioned common responsibilities, attributes and
operations.
Lastly show the relationships from the specialized classes to generalized class.
Security

presentValu
e()
History()

CashAccount Stock Bond Property

interestRat assessments
e
presentValu presentValu presentValue presentValu
e() e() () e()

SmallCapSto LargeCapSto
ck ck
Common Structural Relationships:-
A relationships are classified into two types, they are one-side, two-sided
dependency and generalization/specification.
For a given set of two classes identify whether objects of one class can navigate to the
other class and vice-versa.
Identify a set of two classes with the relationship dependency and find out whether there
exist a two-sided relationship other than dependency.
For each of the associations specify the adornments such as role names, multiplicity,
aggregation etc.
0…
ha Departme 1
School s
1 1. nt
1. . 1. 1.
. . .

member Assigned
To 0
1. 1. ..1
chairpers
attends . teach . on
Instruct
Student Course es 1. or
.
 o n
m
m ism s
C o n
c h a
m e
 Common mechanisms
Uml is made similar by the presence of four
common mechanisms that apply consistently throughout the
language. After constructing or developing the architecture and
different views of a software intensive system, the developer
should go for common mechanisms. We have four types of
common mechanisms. They are….
q Specifications
q Adornments
q Common divisions
q Extensibility
Adornments
Adornments are generally added to an element’s basic
notation and are used to visualize details from the element’s
specification .They are used to decorate a particular thing to
specify some artifacts.
Adornments are classified into two types. They are…..
1. Textual adornments
2. Graphical or symbolic adornments.

Textual adornments
most adornments are rendered by placing text near the
element. Textual adornments are the strings which delineate the
artifacts of a particular thing or relationship or a diagram. Some of
the common textual adornments are name, role names,
multiplicity, isaggregation or not.
Graphical adornments
most adornments are rendered by adding a graphic
symbol to the basic elements. These are the adornments used to
specify the artifacts such as relationships, access specifiers etc. some
of the symbolic adornments are..

publi
c
private

# protected

note
 A note is a special kind of adornment, which is a graphical
symbol for rendering comments or constraints attached to an
element or collection of elements. These are used to specify things
like requirements, observations, reviews and explanations, in
addition to rendering constraints.
A note is rendered in uml using a rectangle with a dog-
eared corner. In uml a note can be rendered in three ways. They
are…..

A note may contain some plain

Simple text text

put an url inside a note

An embedded url
 We may link to or embed another document

Link to
document

Extensibility mechanisms
uml has the capability of extending its vocabulary,
properties, and semantics using one of the mechanisms known as
extensibility mechanisms. This mechanisms permit us to extend the
language in controlled ways.
these mechanisms include…

1. stereo types
2. tagged values
3. constraints
Stereo types
a stereo type extends the vocabulary of the uml,
allowing you to create new kinds of building blocks that are derived
from existing ones but with its own properties, semantics and
notation.

in simplest form a stereo type is rendered as a name

enclosed by guillements
<<metaclass>
Named
ModelElement
stereotype

define an icon for the stereotype and render that icon

to the right of the name
<<exception>>
! Named stereo
underflow
type with icon
 Render an icon as a basic symbol for the stereo typed
item

Stereotyped
element as icon

Tagged values
A tagged value extends the properties of a uml building
block, allowing to create new information in that element’s specific
function.
A tagged value is rendered as a string enclosed by
brackets and placed below the name of another element. That
string includes a name(tag), a separator(=) and a value( of the
tag).

Server
{processor
s=3}
Constraints
A constraint is a condition which is used to add or
modify the existing rules or semantics for a well-formed model we
need to have certain constraints established.
a constraint is generally rendered as a simple statement
or a mathematical equation in a pair of curly braces, and is placed
by side of the thing to which it belongs.
simple constraint
portfolio corporation
Constraint
{secur across
e} multiple
Bank { constraints
Account or}
person
Gender :{f,m} Formal
constraint
Using ocl

{self.wife.gender=fem
ale and
 based on the common mechanisms we can model the
following

modeling comments
modeling new building blocks
modeling new properties
modeling new semantics

Modeling comments
write the comment in the symbol provided and place the note
by side of the element to which it refers.
the note can be elided or it can be made visible
if the note is lengthy, then write down the complete description
in a document and place a link in the note referring the document
as the model evolves keep those comments that are significant ,
otherwise remove
Modeling new building blocks

ü Make sure that the thing which we want to model doesn’t have a
graphical representation in uml
ü After conforming the above select any one of the eleven things
and stereotype it. Stereo typing can be done in two ways
1. Selecting a stereo type which already exists.
2. Creating our own stereo type.
üSpecify new properties and semantics for the new thing.
ü If necessary place a icon for the above stereo type
Modeling new properties
ü make sure that there is no way to express a value using the
attributes of a class
ü in the above situation create a new tag and assign it a value
which we want to model
<<subsystem>>

---
FieldAccess
- {version=2.5
-
Status=checkdin}
---

<<subsystem>> <<subsystem>>

--
Billing AccountsPayable
---

-
{version=3.2 {version=3.2.1
-- -
---

Status=checkout - Status=checkedin
By=edg} }
-
--

<<subsystem>>
WorldCurrency
{version=7.5
Status=checedin}
Modeling new semantics
ümake sure there is no way to model the rules of constraints.
ü write down the constraints and new semantics for the element
which we want to model and place adjacent to it
ü if we want to express the constraints in a more precise way use
ocl as apart of mentioning the constraints

department

member
{subset 1..* 1 manager
}

person
 A diagram is one of the basic building blocks of uml which
group together elements with internal relationships.
According to version 2.0 there are a set of thirteen diagrams
which are used to model a software intensive system in different
views. The diagrams are classified into two types, they are….
1. Static diagrams
2. Dynamic diagrams
The static diagrams model the static behavior of system
where as the dynamic diagrams model the dynamic aspects of a
system.
The static parts of a system uses one of the following
diagrams
1. Class diagrams
2. Object diagram
3. Component diagram
4. Deployment diagram
 The following diagrams are used to view the dynamic parts of a
system

1. use case diagram

2. sequence diagram
3. collaboration diagram
4. state chart diagram
5. activity diagram
 A structural diagram that shows a set
Class diagram of classes, interfaces, collaborations
and their relationships

A structural diagram that shows a set

Object diagram
of objects and relationships

Usecase diagram A behavioral diagram that shows

a set of use cases and actors and
their relationships

Sequence diagram A behavioral diagram that shows an

interaction , emphasizing the time
ordering of messages

Collaboration diagram
A behavioral diagram that shows an
interaction, emphazing the structural
organizations of the objects that send
an d receive messages

State chart diagram A behavioral diagram that shows a

state machine, emphazing the event-
ordered behavior of an object
Activity diagram A behavioral diagram that shows a state
machine, emphazing the flow from activity
to activity
Component diagram
A structural diagram that shows
a set of components and their
relationships
Deployment diagram
A structural diagram that shows a set of
nodes and their relationships
 Using the diagrams of uml the following be modeled.

1. modeling different views of a system

2. modeling different levels of abstraction.
3. modeling complex views
Modeling different views
ü make sure which view best expresses the architecture of our
system
ü after selecting the view decide the various sets of artifacts
which must be captured with that view.
ü decide the types of diagrams which best support the artifacts
which we have captured.
üthe view which we have selected should allow a transitonary
diagram for exploring certain decisions and changes in the project.
Any system which is going to be developed , may be of two
types…..
1. monolithic projects
2. enterprise projects
For a monolithic application that runs on single machine, you
might need only the following diagrams..
quse case view use case diagrams
qdesign view class diagrams ( for structural
modeling)
interaction diagrams ( for behavioral
modeling)
q process view none required
qimplementation view none required
qdeployment none required
 if it is a client/server system, we have to include
component diagrams and deployment diagrams to model the
physical details of your system.
if we are modeling a complex, distributed system, we
need to full range of the uml’s diagrams in order to express the
architecture of your system and technical risks to your project , as in
following…
q use case view use case diagrams
activity diagrams( for behavioral
modeling)
q design view class diagrams ( for structural
modeling)
Interaction diagrams ( for behavioral
diagram)
State chart diagrams( for behavioral
Modeling abstraction

an abstraction is one of the object-oriented

principles which gives the specification by concealing the
implementation.
any system which is under implementation can have
two levels of abstraction.
1. high level abstraction
2. low-level abstraction

to model a system with different levels of abstraction

by using the diagrams consider the following details.

the reader should understand the system and he has to select a

model

if the reader is going to implement or construct the

implementation of a system then he must be provided with a low-
level abstraction i.e. the complete set of artifacts, relations and
specifications.
irrespective of the abstractions selected the reader should
1 . Building blocks or relationships
3. Adornments
5. Flow
4. Stereo types
5. Building blocks
hide those that are not relevant to the intent of
your diagram or the needs of your diagram or the needs of your
reader
8. Adornments
reveal only the adornments of these building
blocks and relationships that are essential to understanding
your intent.
11. Flow
in the context of behavioral diagrams, expand only
those messages or transactions that are essential to
understanding your intent.
14. 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
High level of abstraction

orderfullfillme
Order taker
nt

submitord
er placeorder

acknowledgeOrde
 Low level of abstraction

orderfullfillme Billing
Order taker
nt agent

process
card
submitord
er placeorder triggerBill

acknowledgeOrder
Modeling complex views
To model a system with a high level of abstraction by eliding some
details, you’d lose the information necessary to make these insights.
To model complex views….
Ø If there is no meaningful information present in a high-level abstraction ,elide
some parts of the diagram and retaining the details in other part.
Ø After eliding if still the diagram is complex , group some of the elements in
packages or in high-level of abstractions, then render those packages or
collaborations in your diagram.
Ø If still diagram is complex, use notes and color as visual cues to draw the
readers attention to the points you want to make.
Ø If it is still complex , print it in its entirely 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
 c e d
v a n a l
d
A uctu g r
t r
S del i n
M o
 c e d
v a n
Ad s es
l a s
C
classifier:-
A classifier is a mechanism that describes structural and behavioral
features. The UML provides a number of other kinds of classifiers.

Classes:-
Classes are the most important building block of any object-oriented system. A class is a
description of set of objects that share the same attributes, operations, relationships, and
semantics.
Shape
origin
move()
Resize()
Display()
Interface:-
A collection of operations that are used to specify a service of a class or a
component.

IUnknown
Datatype:-
A type whose values have no identify, including primitive built-in types, as well as
enumeration types.
<<type>>
Int
{values range
from
-2**31-1 to
Signal:- +2**31}
The specification of an asynchronous stimulus communicated between instances.

<<signal
>>
Component:- OffHook
A physical and replaceable part of a system that conforms to and provides the
realization of a interfaces.

Kernel32.
dll
Node:-
A physical element that exists at time and that represents a computational resource.
Generally having at least some memory and often processing capability.

egb_serv
er
Use case:-
A description of a set of a sequence of actions, including variants, that a system
performs that yields an observable result of value to a particular actor.

Process
Subsystem:- loan
A grouping of elements of which some constitute a specification of the behavior
offered by the other contained elements.

<<subsystem
>>
Customer
Service
subsystem
Visibility:-
Visibility is one of the most important details that we can specify using some
symbolic notation the visibility of a feature specifies whether it can be used by other classifies
UML specifies three levels of visible.

Public Any outside classifier with visibility to the given classifier can
use the feature, specified by prepending the
symbol ( + )
Protected Any descendent of the classifier can use the feature, specified by
Prepending the symbol ( # )
Private Only the classifier itself can use the feature, specified by prepending
the symbol ( - ) Toolbar
# currentSelection :
Tool
# toolCount :
+ pickItem(I :
Integer)
+ addTool(t : Tool)
+ removeTool(I :
integer)
+ getTool() : Tool
# checkOrphans()
Scope:-
Scope is an another detail which can be specified for a classifiers ownership. UML
has two keywords which specify the “ scope “ , they are

instance Each instance of the classifier holds its own value for the feature

classifier There is just one value of the feature for all instance of the classifier

it shows a feature that is classifier scoped is rendered by underlining the feature’s

name. No adornment means that the feature is instance scoped.

Frame
Instance
header : scope
FrameHeader
uniqueID : Long
Class scope
Abstract, Root, leaf, and Polymorphic Elements:-
UML uses the notation of writing the names of classes and operations in
Italics to show that they are abstraction.

Root is a keyword which is associated with the name of a class to ensure

that this class does not have any more parents that is, this is the super class.
Leaf is one more keyword which is also associated the name of the class
to ensure that this class cannot be for that extended.
When a message is dispatched at run time, the operation in the hierarchy
that is invoked is chosen polymorphically that is, a match is determined at run time
according to the type of the object. For example, display and isInside are both
polymorphic operations.
 Icon
{root}
Abstract class Origin : point
display()
getID() : Integer
{leaf}

RectangularIc
on
height : ArbitraryIcon
Integer
width : edge :
LineCollection
isInside(p : Point) :
Button Boolean

Display() Concrete Polymorph

class ic
operation
OKButton
{leaf}
Leaf class

display()
Multiplicity:-
The number of instances a class may have is called its multiplicity. In UML we
can specify the multiplicity of a class is specify by writing a multiplicity expression in the upper
right corner of the class. For example, NetworkController is a singleton class. There are exactly
three instances of the class ControlRod in the system.

NetworkController

consolePort [2..*] :
Port

Attribute:-
It can specify the visibility, scope, and multiplicity of each attribute and also the
type, initial value, and changeability of each attribute.
The syntax of an attribute in the UML is

[visibility] name [multiplicity] [: type]

[= initial-value] [{property-string}]
There are three defined properties that you can use with attributes.

changeable There are no restrictions on modifying the attributes value.

addOnly Attributes with a multiplicity greater than one, additional values

may be added, but once created, a value may not be
removed or altered.
frozen The attributes value may not be changed after the object is
Initialized.
Operations:-
It can specify the parameters, return type, concurrency semantics, and other
properties of each operation. The name of an operation plus its parameters is called the
operations signature.

The syntax of an operation in the UML is

[visibility] name [(parameter-list)]
[ : return-type] [{property-string}]
The classifiers for the operations of the class are of two types.

3) Classifiers for the arguments of an operation.

4) Classifiers for the operations it self.

Classifiers for the arguments of an operation:-

The classifiers for the arguments of an operation are also known as
directions. There are three directions available, they are

vin
vout
vinout

in An input parameter, may not be modified.

out An output parameter, may be modified to communicate information to

the
caller.
inout An input parameter, may be modified.
Classifiers for the operations it self:-
There are four classifiers available in UML for the operations of a class, they
are
visQuery
vsequential
vguarded
vconcurrent

isQuery Execution of the operation leaves the state of the system

unchanged.
In other words, the operation is a pure function
that has no side effects.
sequential Callers must coordinate outside the object so that only one flow is
in the object at a time. In the presence of multiple
flows of control, the semantics and integrity of the
object cannot be guaranteed.
guarded The semantics and integrity of the object is guaranteed in the
presence of multiple flows of control by
sequentializing all calls to all of the objects
guarded operations.
Concurrent The semantics and integrity of the object is guaranteed in the
presence of multiple flows of control by treating the operation as
atomic.

Template Classes:-
A template is a parameterized element. We can write template classes, each of which
defines a family of classes. A template includes slots for classes, objects, and values. The result
is a concrete class that can be used just like any ordinary class.
Template
parameters
Template class Item
Value
Map Buckets :
int
+ bind(in I : Item; in v : value) :
Boolean
+ isBound(in I :item) : Boolean

<<bind>> (Customer,
Implicit binding Order, 3)
Map<Customer, explicit binding
Order, 3> OrderMa
p
Standard Elements:-
In UML’s extensibility mechanisms apply to classes. Most often, we will use
tagged values to extend class properties and stereotypes to specify new kinds of components.
There are four standard stereotypes that are used, they are

ØMetaclass
ØPowertype
ØStereotype
ØUtility

metaclass Specifies a classifier whose objects are all classes.

powertype Specifies a classifier whose objects are the children of a given

stereotype Specifies
parentthat the classifier is a stereotype that maybe applied to

utility Specifies a class whose attributes and operations are all class
other elements.

scoped.
Common Modeling Techniques:-
Modeling the semantics of class:-
In the advanced structural modeling for a class the following are the set
of common modeling techniques available.

üSpecify the responsibility of the class.

üSpecify the semantics of the class.
üSpecify the source code of each and every operation in the class.
üSpecify the preconditions & post conditions of each operation in the class.
üSpecify the state machines.
üSpecify the collaborations.
 c ed
v a n i p s
d
A ion s h
l a t
Re
 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 a 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 effect another thing, but not necessarily the reverse.
Graphically, a dependency is rendered as a dashed line, directed to the thing.
UML defines a number of stereotypes that may be applied to dependency
relationships. There are 17 such stereotypes, all of which can be organized into six
groups.

There are 8 stereotypes that apply to dependency relationships among classes and
objects in class diagram.
bind Specifies that the source instantiates the target
template using the
given actual parameters.

derive Specifies that the source may be computed from

the target.

friend Specifies that the source is given special visibility

into the target.

instanceOf Specifies that the source object is an instance of

the target classifier.

instantiate Specifies that the source creates instances of the

target.

powertype Specifies that the target is a powertype of the

source i.e., whose
objects are all the children of a given parent.

refine Specifies that the source is at a finer degree of

Stereotypes for packages:-
access Specifies that the source package is granted the right to reference the
elements of the target package.

import Specifies that the public contents of the target package enter the flag
namespace of the source.
Stereotypes for use cases:-
extend Specifies that the target use case extends the behavior of the source.

include Specifies that the source use case explicitly incorporates the
behavior of another use case.
Stereotypes for Interaction:-
become Specifies that the target is the same object as the source but at a later
point in time wit different values states & roles.

call Specifies that the source operation invokes the target operation.

copy Specifies that the target object design exact, but independent, copy of
the source.
Stereotypes for state machine:-
send Specifies that the source operation sends the target event.

trace Specifies that the target is an historical ancestor of the source.

Generalization:-
A Generalization is a relationship between a general thing and a more specific kind of
that thing. The relationship generalization is having only one stereotype
i.e., implementation which models the “ private inheritance “.
The generalization relationship is having 4 standard constraints, they are
qcomplete
qincomplete
qdisjoint
qoverlapping

complete Specifies that all children in the generalization have been specified
in the model and that no additional children are permitted.

incomplete Specifies that not all children in the generalization have been
specified and that additional children are permitted.
 disjoint Specifies that objects of the parent may have no more than one of
the children as a type.

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. Graphically, an association is rendered as a solid line connecting
the same or different classes.
Association is bi-directional relationship. In UML which is having the following
stereotypes.

vNavigation
vVisibility
vQualification
vInterface Specifies
vComposition
vAssociation Class
Navigation:-
At times the navigation between the two entities participating than association is
unidirectional in order to implement this UML provides a concept known as navigation using a
directed arrow or a filled triangle.
1 *
user password

Visibility:-
In UML, we can specify three levels of visibility for the association ends, Generally
applied to the role names, public(+),private(-),protected(#).

1 * 1 *
UserGroup user Password
Qualification:-
The stereotype qualification implements the concept of
“ relationship attributes “. UML uses at different concept known as qualification by which a
qualifier is mentioned at any of the ends of the relation. Using a small rectangle.

jobID : * 0… ReturnedIte
WorkDesk 1
Int m

Interface Specifier:-
Using interface specifies we mentioned the names of the interfaces implements
by each role names of an association relationships.

Worker :
IEmployee

Person
Supervisor :
IManager
Composition:-
A composition is one of the forms of association which implements the relationship
whole / part, such relationship are often known as aggregation but an aggregation with a
multiplicity of exactly one at any of the ends is known as composition.
window
1

*
Association Classes:- Frame
In an association between two classes, the association if self may have some
properties, UML provides 4 standard properties or adornments they are name, role names,
multiplicity & aggregation.

Compan * 1
..* Person
y

Job
descriptio
n
dateHired
salary
Constraints:-
These simple and advanced properties of associations are sufficient for most of the
structural relationships.UML defines five constraints they are

implicit Specifies that the relationship is not manifest but, rather, is only
conceptual.
ordered Specifies that the set of objects at one end of an association are
in an explicit order.
changeable Links between may be added, removed, and changed freely.

addOnly New links may be added from an object on the opposite end of the
association.
frozen A link, once added from an object an the opposite end of the
association, may not be modified or deleted.
Realization:-
A realization is a semantic relationship between classifies in which one classifier
guarantees to carry out. Graphically, a realization is rendered as a dashed directed line with a
open hallow head.

<<interface> Realizatio
> n
IRuleAgent ----------------- AccountBusinessR
addRule() ules
changeRule(
) Realization of an interface
explainActio
Common Modeling Technique:-
Modeling Webs of Relationships:-
v Identify the use cases & synonyms.
v Start by modeling the structural relationships.
v Identify for any generalization or specialization relationships.
v After the above steps completion only proceed for looking dependencies.
v Identify each kind of relationship and if necessary apply the advanced features.
v Don’t try for modeling all kinds of relationships in a single diagram or view.
 e s
ka g
ac
p
 A package is a general –purpose mechanism for organizing elements into rules.
Graphically, a package rendered as a tabbed folder.

Concepts:-
ØNames
ØOwned Elements
ØVisibility
ØImporting and Exporting

Names:-
A name is a textual string. That name alone is known as a simple name. A package is
typically drawn showing only its name.

client
+OrderForm Sensors::visi
+ on
TrackingFor
Simple names Path names
m
Owned Elements:-
üA package may contain classes, interfaces, components, nodes, collaborations.
ü A package forms a namespace in which duplication of the names of same elements
is
not possible.
üElements of different kinds may have same name with in a package.
üPackages may own other packages.
Clien
Clien t
t
+ +
Orderform OrderForm
+ -
TrackingFor Order
m
+
- Order
TrackingFor
m
Visibility:-
visibility of an element owned by a package by prefixing the elements name with an
appropriate visibility symbol. Public elements are rendered by prefixing their name with a +
symbol, as for OrderForm. Collectively, the public parts of a package constitute the package’s
interface. It is rendered by prefix in the elements name with a# symbol and a – symbol
respectively.

Importing and Exporting:-

In the UML, we model an import relationship as a dependency adorned with the
stereotype import. By packaging we abstractions into meaningful chunks and then controlling
their access by importing.
The parts that one package exports are visible only to the contents of those packages
That explicitly import the package.
Server Client
+ Database + Orderform
+ +
LoggingServi TrackingFor
ce m
expor
ts
Policie <<import
s >>
+
OrderRules
-
GUI::Window import

GUI <<import>
+ Window >
+ Form
#
EventHandle
r
Importing and exporting
Generalization:-
Generalization among packages is very much like generalization among classes. The package GUI is
shown to export two classes. Packages involved in generalization relationships follow te same principle of
substitutability as do classes

GUI
+ Window
+ Form
#
eventHandler

WindowsG
UI
+ GUI::Window
+ Form
#
GUI:EventHandl MacGUI
er
+ VBForm
Standard Elements:-
All the UML’s extensibility mechanisms for also applicable to package.UML defines a
set of 5 standard stereo types which are applicable only two packages, they are

ØFacade
ØFramework
ØStub
ØSubsystem
ØSystem

facade Specifies a package that is only a view on some other package

framework Specifies a package consisting mainly of pattern
stub Specifies a package that serves as a proxy for the public contents of
another package
subsystem Specifies a package representing an independent part of the entire
system being modeled
system Specifies a package representing the entire system being modeled
Common Modeling Techniques:-
Modeling Groups of Elements:-
v Scan the modeling elements in a particular architectural view.

v Surround each of these clumps into a package.

v After forming the package mention the visibility of various elements present in the
package.
v If necessary specify the generalization among the packages.
Modeling Architectural Views:-
Packages are generally used to model the different views of an architectural
a view is a projection into any organization & structure of the system.

v Identify the architectural views that are significant for the problem.
v Place the elements(diagrams) that are necessary and sufficient to visualize, specify,
construct & document the semantics of the package.
v If necessary group the elements further into way own package.
 Interfaces

v Interfaces define a line between the specification of what an

abstraction does and the implementation of how that abstraction does
it. An interface is a collection of operations that are used to specify a
service of a class or a component.

v We use interfaces to visualize, specify, construct and document

the seams within your system. Types and roles provide a mechanism
for you to model the static and dynamic conformance of an
abstraction to an interface in a specific context.

v A well-structured interface provides a clear separation between

the outside view and the inside view of an abstraction, making it
Terms and concepts of interface
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, an interface may be drawn
showing only its name.

Iunknown
Networking::IRouter

simple names path

names

Ispell Isensor
Sensors::ITarget
Operations
an interface is a named collection of operations used to
specify a service of a class or of a component. 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.
when we visualize an interface in its normal form as a circle, w
suppress the display of these operations. We can render an interface as a
stereotyped class, listing its operations in the appropriate compartment.
Operations may be drawn showing only their name, or they may be
augmented to show their full signature and other properties.

<<interface>>
url
stereotype StreamHandler

openConnectio
n()parse URL()
setURL()
operations toExternalForm
()

operations
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 classifier guarantees to carry out. We can show that an element realizes an interface
in two ways.

Ø simple form in which the interface and its realization relationship are rendered as a lollipop
sticking off to one side of a class or component. This is useful when you simply want to expose
the seams in your system.

Ø second, you can use the expanded form in which you render an interface as a stereotyped
class, which allows you to visualize its operations and their properties, and then draw a
realization relationship from the classifier or component to the interface.

in UML a realization is rendered as a dashed directed line with a large open arrow head
pointing to the interface. This notation is cross between generalization and dependency.
in both cases, you attach the class or component that builds on an interface with a
dependency relationship from the element to the interface.
 dependency

TargetTracker
Tracker ---------
observ
er Realization(simple
Java::Util::Observa form)
ble

interfa
ce
Target dependency
Id <<interface
currentPosition >>
-------- Observer
TargetTracker
setPosition()
setVelocity() Update()
expectedPositi
on()
Realization(exapanded
form)
 Types and roles
Types and roles provide a mechanism for you to model the static and
dynamic conformance of an abstraction to an interface in a specific
context.
A type is a stereotype of a class used to specify a domain of objects,
together with operations applicable to the object.
A role is the behavior of an entity participating in a particular context.

interface
<<interface>>
association
Employee
person Company
getEmploymtHisto
ry()
e:Employee
getCompensation(
)
getBenefits()
class
class

role
Common modeling techniques
There are two common modeling techniques

modeling the seams in a system

modeling static and dynamic types

Modeling the seams in a system

To model the seams in a system
Within the collection of classes and components, draw a line around
those that tend to be tightly coupled relative to other sets of classes and
components.
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 such collaboration identify the interfaces it relies on those it provides
to others. Model importing interfaces by relationships, and exporting by
realization relationships.
 <<interface>>
Iunknown

QueryInterface():HRE
SULT
AddRef():ULONG
Release():ULONG

<<interface>>
ITransaction

ILedger Start()
Ledger.dll PerformAction()
Commit()
Rollback()
Exceptions
IReports failure

Modeling the seams in a

system
Modeling static and dynamic types

Modeling the static nature of an object can be visualized in a class

diagram.
To model a dynamic type…
Specify the different possible types of that object by rendering each
type as a class stereotyped as type or as interface.
Model all the roles the class of the object may take on at point in time.
We can do in two ways.
7. First, in a class diagram, explicitly type each role that the class
plays in its association with other classes.
8. Second, also in class diagram, specify the class-to-type
relationships using generalization.
In an interaction diagram, properly render each instance of the
dynamically typed class. Display the role of the instance in brackets
below the object’s name.
To show the change in role of an object, render the object once for each
 <<type>>
<<type> Employee
> <<type>>
Canditate Retiree

person

Modeling static
types

<<become>
> P:person
P:person [employee
[Canditate] ]

Hire( HRDepartme
) nt

Modeling dynamic