UNIT-1

CHAPTER-2
 Introduction To UML
 The Unified Modeling Language (UML) is a standard
language for writing software blue prints.

 The UML is appropriate for modeling systems ranging

from enterprise information systems to distributed web-
based applications and even real time embedded
systems.

 The UML is process independent.

The UML is a language for
1) Visualizing
2) Specifying
3) Constructing
4) Documenting
 The UML is a Language.
 What is a Language?

 What is a modeling language?

 A modeling language is a language whose vocabulary
and rules focus on the conceptual and physical
representation of a system.

 Modeling yields an understanding of a system.

 UML is a language for visualizing
 Text is a wonderful minimal and direct way to write
expressions and algorithms.
In such cases, the programmer is still doing modeling.

Why?
There are several problems with this
1) Communicating the conceptual models to others is
error-prone unless everyone involved speaks the same
language.
2) There are some things about a software system you
can’t understand unless you build models that
transcend the textual programming language.
(Example : Class hierarchy)
3) If the developer who cut the code never wrote down the
models that are in his or her head, that information
would be lost forever or, at best, only partially
recreatable from the implementation, once that
developer moved on.
 UML is a language for Specifying
 Specifying means building models that are precise,
unambiguous and complete.

 The UML addresses the specification of all the

important analysis, design and implementation
decisions that must be made in developing and
deploying a software system.
 UML is a language for Constructing
 The UML is not a visual programming language, but its
models can be directly connected to a variety of
programming languages, such as JAVA, C++ or Visual
Basic or even to Tables of database.

 Forward Engineering
 Reverse Engineering
 UML is a language for Documenting
 A software organization produces all sorts of artifacts in
addition to row executable code. The artifacts including
the following:

-Requirements -Project Plan

-Architecture -Tests
-Design -Prototypes
-Source Code -Releases.
 UML Application Areas
 The UML is intended primarily for Software intensive
systems. It has been used effectively for such domains
as follows:

• Enterprise information systems

• Banking and financial services
• Telecommunications
• Transportation
• Defense
• Medical , Electronics, scientific and Distributed web-
based services.
 A Conceptual Model of the UML
 To understand the UML, a conceptual model of the
language is need to form and it requires the three major
elements:

1. Building blocks of the UML.

2. Rules that dictate how these building blocks may be put
together.
3. Common mechanisms that apply throughout the UML.
 1. Building blocks of the UML
 The UML consists of three kinds of building blocks:

a) Things- These are the abstractions that are first-class

citizens in a model.

b) Relationships-Tie the above things together.

a) Diagrams-Group interesting collections of things,

 Building Blocks of UML

Things Relationships Diagrams

Class, Interface,
Active class, Use case,
Structural Component, Use case,
Dependency,
Collaboration, Node Class,
Generalization,
Object,
Associations,
Sequence,
Realization
Behavioral Collaboration,
Interaction,
State chart,
State Machine
Activity,
Component,
Grouping Package
Deployment.

Annotational Note
Things in the UML
 There are 4 kinds of things in the UML

1. Structural Things
2. Behavioral Things
3. Grouping Things
4. Annotational Things
 1. Structural Things

 Structural things are the nouns of UML models. These

are mostly static parts of a model, representing
elements that are either conceptual or physical.

 There are 7 kinds of Structural things:

1. Class
2. Interface
3. Collaboration
4. Use case
5. Active class
6. Component
7. Node
(1) Class:-
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.

Window Name
Origin
Size Attributes
class Open( )
Close( )
Operation
Move( )
Display( )
(2) Interface:-

 Interface is a collection of operations that specify a

service of a class or component.

 An interface describes the externally visible behavior of

that element.(complete or part of )
 An interface defines a set of operation specifications but
never a set of operation implementations.

 Graphically, an interface is represented as a circle with

its name.

ISpelling

Interface
(3) Collaboration:-
 A collaboration defines an interaction and is a society of
roles and other elements that work together to provide
some cooperative behavior.

 Therefore, collaboration have structural as well as

behavioral dimensions.

 Graphically a collaboration is represented as an ellipse

with dashed lines, usually including only its name.
(4) Use case:-

 A Use case is a description of set of sequence of actions

that a system performs, which results a value to a
particular actor.

 A use case is used to structure the behavioral things in a

model.
 A use case is realized by a collaboration.

Withdraw money

Use case
 The remaining three things- Active classes, components
and nodes- all are class like, ie., they also describe a
set of objects that share the same attributes, operations,
relationships and semantics.
(5) Active class:-
 An active class is a class whose objects own one or
more processes or threads and therefore can initiate
control activity.

 Active Class initiate and control the flow of activity, while

passive classes store data and serve other classes.
We illustrate active classes with a thicker border.
 Graphically, an active class is represented like a
class, but with heavy lines, usually including its
name, attributes and operations.

Event manager

Suspend()
Flush()

Active class
 The remaining two elements –component and nodes-
they represent physical things, where as previous five
things ( class, interface, collaboration, usecase, active
class) represent conceptual or logical things.
(6) Component:-
 A component is a physical and replaceable part of a
system that conforms to and provides the realization of a
set of interfaces.

 A component represents the physical packaging of

logical elements such as classes, interfaces and
collaborations.
orderform.java

Component
(7) Node:-

 A node is physical element that exists at run-time and

represents a computational resource, generally having
some memory and processing capability.

 A set of components may reside on a node and may also

migrate from node to node.
Database
server

Node
 2. Behavioral Things
 These are the dynamic parts of UML models.

 These are the verbs of a model representing the

behavior over time and space.

 There are two types of behavioral things

1. Interaction
2. State machine.
(1) Interaction:-

 An Interaction is a behavior that comprises a set of

messages exchanged among a set of objects within a
particular context to perform a specific purpose.

display

Message
 An interaction involves a number of other elements,
including messages, action sequences and links.
(connection between objects.)
2. State machine:-

A State machine is a behavior that specifies the

sequences of states an object or an interaction goes
through during its lifetime in response to events, together
with its responses to those events.

waiting

State
 A State machine involves a number of other elements,
including states, transitions( the flow from state to state),
events (things that trigger a transition), and activities
( the response to a transition).
 3. Grouping Things
 Grouping things are the organizational parts of UML
models.

 In all, there is one primary kind of grouping thing,

namely, Package.

 Package:- A Package is a general-purpose

mechanism for organizing elements into groups.
 Structural things, behavioral things and even other
grouping things that may be placed in a package.

 Unlike component (which exist at run time), package is

purely conceptual (meaning that it exist only at
development time).
Business rules

Package
 4. Annotational Things
 Annotational Things are the explanatory parts of the
UML models.

 These are the comments you may apply to describe,

illuminate and remark about any element in a model.

 There is one primary kind of Annotational thing, called

a Note.
 Note:- A Note is simply a symbol for representing
constraints and comments attached to an element or a
collection of elements.

 A note is rendered as a rectangle with a

dog-eared corner.

Return copy of self

Note
2. Relationships in the
UML
 There are four kinds of relationships in the UML.
1. Dependency
2. Association
3. Generalization
4. Realization

These relationships are the basic relational building

blocks of the UML. These are used to write well-formed
models.
 DEPENDENCY:-

 A Dependency is a semantic relationship between two things in

which a change to one thing( the independent thing) may affect the
semantics of the other thing (the dependent thing).

Dependencies
 ASSOCIATION:-

 An Association is a structural relationship that describes a set of

links, a link being a connecting among objects.

 Aggregation is a special kind of association, representing a

structural between a whole and its parts.
 An association is represented as a solid line, possibly directed,
occasionally including a label, and often containing other
adornments, such as multiplicity and role names.

0..1 *
employer employee

Association
 GENERALIZATION:-

 A generalization is a specialization/generalization relationship in which

objects of the specialized elements (the child) are substitutable for
objects of the generalized elements (the parent).

 In this way, the child shares the structure and the behavior of the
parent.
 Represented as a solid line with a hollow arrow head pointing to the
parent.

Generalization
 REALIZATION:-
 A realization is a semantic relationship between classifiers, wherein
one classifier specifies a contract that another classifier guarantees
to carryout.

 We will encounter realization relationships in two places: between

interfaces and classes or components that realize them, and
between use cases and the collaborations that realize them.

Realization
3. Diagrams in the UML
 A diagram is the graphically presentation of a set of elements, most
often represented as a connected graph of vertices (things) and
arcs (relationships).

 Diagrams visualize a system from different perspectives, so a

diagram is a projection into system.
 The UML includes nine 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
 A class diagram shows a set of classes, interfaces, and
collaborations and their relationships.

 These diagrams are the most common diagrams found in modeling

object-oriented systems.

 Class diagram address the static design view of a system.

2. Object Diagram
 An object diagram shows a set of objects and their relationships.

 Object diagrams represent static snapshots of instances of the

things found in class diagram.
3. UseCase Diagram
 Use case diagram shows a set of use case and actors (a special
kind of class) and their relationships.

 Use case diagrams address the static use case view of a system.

 These diagrams are especially important in organizing and modeling

the behaviors of a system
(4) & (5) Sequence and Collaboration diagrams
 Both sequence diagrams and collaboration diagrams are kind of
interaction diagrams.

 An interaction diagram shows an interaction, consisting of a set of

objects and their relationships, including the messages that may be
dispatched among them.

 Interaction diagram address the dynamic view of a system.

 A sequence diagram is an interaction diagram that emphasizes the
time ordering of messages.

 A collaboration diagram is an interaction diagram that emphasizes

the structural organization of the objects that send and receive
messages.

 Sequence diagrams and collaboration diagrams are isomorphic,

meaning that you take one and transform it into the other.
6. State Chart Diagram
 A statechart diagram shows a state machine, consisting of states,
transitions, events and activities.

 Statechart diagram address the dynamic view of a system.

7. Activity Diagram
 An activity diagram is a special kind of a statechart diagram that
shows the flow from activity to activity within a system.

 Activity diagram address the dynamic view of a system.

8. Component Diagram
 A component diagram shows the organizations and dependencies
among a set of components.

 Component diagram address the static implementation view of a

system.
9. Deployment Diagram
 A deployment diagram shows the configuration of run-time
processing nodes and the components that live on them.

 Deployment diagram address the static deployment view of an

architecture.
2. Rules of the UML:-
 The UML’s building blocks cant simply be thrown together in a
random fashion.

 Like any language, the UML has a number of rules that specify what
a well-formed model should look like.
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.

3.Common Mechanisms
 The 4 common mechanisms that apply consistently throughout
the language.

1. Specifications
2. Adornments
3. Common Divisions
4. Extensibility mechanisms
1. Specifications:-

 The UML is more than just a graphical language. Rather, behind

every part of graphical notation there is a specification that
provides a textual statement of the syntax and semantics of that
building block.

 For example, behind a class icon is a specification that provides

the full set of attributes, operations and behaviors.

 You use the UML’s graphical notation to visualize a system; you

use the UML’s specification to state the system details.
2. Adornments:-
 Adornments Textual/graphical items added to the basic notation of
an element.
 Used for visualizing details from the element’s specification
 Example: The basic notation of association is a line, but this could
be adorned with additional details, such as the role and multiplicity
of each end.
 The most important kind of adornments are notes.

0..1 *

Employer Employee
3.Common Divisions

 Abstraction vs. manifestation

• Class vs. object
• Most UML building blocks have this kind of class/object
distinction.

 Interface vs. implementation

• An interface declares a contract, and an implementation
represents one concrete realization of that contract.
 Customer Jan :Customer
name
address :Customer
phone
Elyse

Classes and Objects

IUnknown

SpellingWizard.dll

ISpelling

Interfaces and Implementations

4.Extensibility Mechanisms

 Allows you to extend the language by adding new building

blocks, creating new properties and specifying new semantics.
Includes:

1. Stereotypes
2. Tagged values
3. Constraints
 Stereotypes

 Extend the vocabulary of the UML by creating new model elements

derived from existing ones but that have specific properties suitable
for your domain/problem.
 Stereotype EventQueue
Tagged
{version =3.2 value
<< Exception>> Author=egb }
Overflow

add( ) {ordered}

remove( )
flush( ) Constraints

Extensibility Mechanisms
• Graphically, a stereotype is rendered as a name
enclosed by guillemots and placed above the name of
another element (eg, <<name>>)

• Alternatively, you can render the stereotyped element by

using a new icon associated with that stereotype
 Named stereotype <<metaclass>>
Model Element

 Named stereotype with icon

<<exceptions>>
Underflow !

 Stereotyped element as icon

HumiditySensor
2.Tagged values:-

• Properties for specifying key-value pairs of model elements, where

keywords are attributes.

• Extend the properties of a UML building block, allowing you to

create new information in that elements specification.

• Can be defined for existing elements of the UML

 Stereotype EventQueue
Tagged
{version =3.2 value
<< Exception>> Author=egb }
Overflow

add( ) {ordered}

remove( )
flush( ) Constraints

Extensibility Mechanisms
3.Constraints:-

 Properties for specifying semantics or conditions that must be

maintained as true for model elements.

 Extend the semantics of a UML building block, allowing you to add

new rules, or modify existing ones.

 Example:- you might want to constrain the EventQueue class so

that all additions are done in order.
 Stereotype EventQueue
Tagged
{version =3.2 value
<< Exception>> Author=egb }
Overflow

add( ) {ordered}

remove( )
flush( ) Constraints

Extensibility Mechanisms
 Architecture
 Modeling a System's Architecture
Architecture is set of significant
decisions about
 The organization of the system
 Selection of structural elements and their interfaces
 Their behavior ,as specified in the collaborations among those
elements
 Composition of these structural and behavioral elements
 The architectural style that guides this organization (static dynamic
elements ,interfaces ,collaborations and their compositions)
Use case view
 The use case view of a system includes the use cases that
describe the behavior of the system as seen by its end users,
analysts, and testers.

 This view doesn’t specify the organization of a software system.

Rather, it Specify the shape of the system's architecture.

 The static aspects of this view are captured in use case

diagrams;
and the dynamic aspects of this view are captured in interaction
diagrams, statechart diagrams, and activity diagrams.
Design view
 The design view of a system includes the classes, interfaces, and
collaborations that form the vocabulary of the problem and its
solution.

 This view primarily supports the functional requirements of the

system, meaning the services that the system should provide to
its end users.

 The static aspects of this view are captured in class diagrams

and object diagrams and the dynamic aspects of this view are
captured in interaction diagrams, statechart diagrams, and
activity diagrams.
Process view
 The process view of a system includes the threads and processes
that form the system's concurrency and synchronization
mechanisms.

 This view primarily addresses the performance, scalability, and

throughput of the system.

 The static and dynamic aspects of this view are captured in the
same kinds of diagrams as for the design view, but with a focus
on the active classes that represent these threads and processes.
Implementation view
 The implementation view of a system includes the components
and files that are used to assemble and release the physical
system.

 This view primarily addresses the configuration management of

the system's releases, made up of somewhat independent
components and files that can be assembled in various ways to
produce a running system.

 The static aspects of this view are captured in component

diagrams; the dynamic aspects of this view are captured in
interaction diagrams, statechart diagrams, and activity
diagrams.
Deployment view
 The deployment view of a system includes the nodes that form the
system's hardware topology on which the system executes.

 This view primarily 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, statechart diagrams, and activity
diagrams.
 S/w Development Life cycle
 The UML is largely process-independent, meaning that it is not tied
to any particular software development life cycle.

 However, to get the most benefit from the UML, you should consider
a process that is
 Use case driven
 Architecture-centric
 Iterative and incremental
 Use case driven means that use cases are used as a primary
artifact for establishing the desired behavior of the system, for
verifying and validating the system's architecture, testing,
communicating among the stakeholders of the project.

 Architecture-centric means that a system's architecture is used

as a primary artifact for conceptualizing, constructing, managing,
and evolving the system under development.

 An iterative process is one that involves managing a stream of

executable releases. It involves the continuous integration of the
system's architecture to produce these releases, with each new
release embodying incremental improvements over the other.
 Together, an iterative and incremental process is risk-driven,
meaning that each new release is focused on attacking and
reducing the most significant risks to the success of the project.

 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 whether to move into the next
phase.
 There are four phases in the software development life cycle:
inception, elaboration, construction, and transition.
 Inception is the first phase of the process, the basic idea for the
development.

 Elaboration is the second phase of the process, the product vision

and its architecture are defined.

 Construction is the third phase of the process, the software is

brought from an executable architectural baseline to being ready to
be transitioned to the user community.

 Transition is the fourth phase of the process, when the software is

turned into the hands of the user community.