Unit – II (Part 1)

Object Oriented Analysis and Design 1

UNIT- II
Introduction to UML

UNIT II: Introduction to UML: Importance of modeling, principles of modeling, object oriented modeling,
conceptual model of the UML, Architecture, and Software Development Life Cycle

The Unified Modeling Language (UML) is a standard language for writing software blueprints.
The UML may be used to visualize, specify, construct, and document the artifacts of a software -intensive
system.
Importance of modeling
“A model is a simplification of reality.”
• A successful software organization is one that consistently deploys quality software that meets the
needs of its users.
• An organization that can develop such software in a timely and predictable fashion, with an efficient
and effective use of resources, both human and material, is one that has a sustainable business.
• Unsuccessful software projects fail in their own unique ways, but all successful projects are alike
in many ways.
• There are many elements that contribute to a successful software organization; one common
thread is the use of modeling.

“Modeling is a proven and well -accepted engineering technique.”

• We build architectural models of houses and high rises to help their users visualize the final product.
• We may even build mathematical models in order to analyze the effects of winds or earthquakes on
our buildings.
Why do we model? There is one fundamental reason .
• “ We build models so that we can better understand the system we are developing.”
Through modeling, we achieve four aims .
1. Models help us to visualize a system as it is or as we want it to be.
2. Models permit us to specify the structure or behavior of a system.
3. Models give us a template that guides us in constructing a system.
4. Models document the decisions we have made.

Why do we model the large and complex systems?

• “ We build models of complex systems because we cannot comprehend such a system in its
entirety .”
Principles of modeling
The use of modeling has a rich history in all the engineering disciplines. That experience suggests
four basic principles of modeling.
1. The choice of what models to create has a profound influence on how a Problem is attacked
and how a solution is shaped.
2. Every model may be expressed at different levels of precision.
3. The best models are connected to reality.
4. No single model is sufficient. Every nontrivial system is best approached through a small
set of nearly independent models.
1
PSCMR CET (R20)
 Unit – II (Part 1)
Object Oriented Analysis and Design 2

Object -Oriented Modeling

• In software, there are several ways to approach a model. The two most common ways are from an
algorithmic perspective and from an object- oriented perspective.
 Algorithmic perspective :
o It i s the traditional view of software development.
o In this approach, the main building block of all software is the procedure or function.
o This view leads developers to focus on issues of control and the decomposition of larger
algorithms into smaller ones.
o As requirements change and the system grows, systems built with an algorithmic focus
turn out to be very hard to maintain.
o Language dependent .
o Algorithm/ Process dependent
 Object -oriented perspective :
o It i s the contemporary view of software development. In this approach.
o The main building block of all software systems is the object or class.
o An object is a thing, generally drawn from the vocabulary of the problem space or the
solution space; a class is a description of a set of common objects.
o Every object has identity (name, distinguish it from other objects), state (some data
associated with it), and behavior (do things to other objects, as well).
o With Object -oriented perspective (diagrammatic representation) it is very easy to
visualize the system.
o No language dependent and it is n o process dependent .

Conceptual model of the UML

 A conceptual model is the first step before drawing a UML diagram. It helps to understand the
entities in the real world and how they interact with each other.
 Conceptual model of UML can be mastered by learning the following three major elements:
 UML building blocks
 Rules to connect the building blocks
 Common mechanism s of UML
 Building blocks of the UML: The vocabulary of the UML encompasses three kinds of building:
1. Things
2. Relationships
3. Diagrams

1. Things are the abstractions that are first -class citizens in a model; relationships tie these
things together; diagrams group interesting collections of things.
Things are the most important building blocks of UML. Things can be:
i. Structural things
ii. Behavioral things
iii. Grouping things
iv. Annotational things

2
PSCMR CET (R20)
 Unit – II (Part 1)
Object Oriented Analysis and Design 3

i. Structural Things
• Structural things are the nouns of UML models.
• These are the mostly static parts of a model.
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. Graphically, a class is rendered as a rectangle.

Interface
• Interface defines a set of operations which specify the
responsibility of a class or component.
• An interface might represent the complete behavior of a class or component or only a
part of that behavior.

Collaboration
• Collaboration defines an interaction and is a society of roles and other elements that work
together to provide some cooperative behavior that's bigger than the sum of all t he
elements.

Use case
• Use case represents a set of actions performed by a system for a specific goal.

Active Class
• An active class is a class whose objects own one or more processes or threads
and therefore can initiate control activity.
• An act ive class is just like a class except that its objects represent elements whose
behavior is concurrent with other elements.

3
PSCMR CET (R20)
 Unit – II (Part 1)
Object Oriented Analysis and Design 4

Component
• A component is a physical and replaceable part of a system that conforms to and provides
the realization of a set of interfaces.

Node
• Node is a physical element that exists at run time and represents a computational
resource, generally having at least some memory and, often , processing capability.

ii. Behavioral things

• A behavioral thing consists of the dynamic parts of UML models. Following are the
behavioral things:
Interacti on
• Interaction is defined as a behavior that consists of a group of messages exchanged among
elements to accomplish a specific task.

State machine
• It defines the sequence of states an object goes through in response to events. Events are
external factors responsible for state change.

iii. Grouping things

• Grouping things are the organizational parts of UML models. There is only one
grouping thing available:
Package
• Package is the only one grouping thing available for gathering structural and behavioral
things.

4
PSCMR CET (R20)
 Unit – II (Part 1)
Object Oriented Analysis and Design 5

iv. Annotational things

• Annotational things are the explanatory parts of UML models.
• These are the comments we may apply to illuminate, describe and capture remarks of
UML model elements.
Note
• A note is used to render comments, constraints etc of an UML element.

2. Relationships
• It is another most important building block of UML.
• It shows how elements are associated with each other and this association describes the
functionality of an application.
There are four kinds of relationships available.
Dependency
• Dependency is a semantic relationship between two things in which change in one element
may affects the other one.

Association
• Association is structural relationship that describes a set of links that connects elements
of an UML model.
• We can have unidirectional association as well as bi -directional association

Association
Generalization

 Generalization is a specialization/ generalization relationship in which objects of the

specialized element (the child) are substitutable for objects of the generalized element (the parent)..
 Graphically, a generalization relationship is rendered as a solid line with a hollow
arrowhead pointing to the parent .

Realization
• Realization is a semantic relationship between classifiers, wherein one classifier
specifies a contract that another classifier guarantees to carry out.
• Graphically, a realization relationship is rendered as a cross between a generalization
and a dependency relationship

5
PSCMR CET (R20)
 Unit – II (Part 1)
Object Oriented Analysis and Design 6

3. UML Diagrams
• A diagram is the graphical presentation of a set of elements, most often rendered as a connected
graph of vertices (things) and arcs (relationships).
• All the elements, relationships are used to make a complete UML diagram and the diagram
represents a system.
• The visual effect of the UML diagram is the most important part of the entire process.

• UML includes the following nine diagrams and the details are described in the following
chapters.

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

 Rules of the UML

1. The UML's buil ding blocks can't simply be thrown together in a random fashion.
2. Like any language, the UML has a number of rules that specify what a well -formed model
should look like.
3. A well -formed model is one that is semantically self -consistent and in harmony with al l its related
models.
The UML has semantic rules for

 Name : 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

4. The development of a software -intensive system may be viewed by many stakeholders in

different ways and at different times.
5. 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

6
PSCMR CET (R20)
 Unit – II (Part 1)
Object Oriented Analysis and Design 7

Common Mechanisms in the UML

• UML is made simpler by the presence of four common mechanisms that apply consistently
throughout the language.
1. Specifications
2. Adornments
3. Common divisions
4. Extensibility mechanisms

1. Specifications
• The UML is mo re than just a graphical language.
•
Rather, behind every part of its graphical notation there is a specification that provides a
textual statement of the syntax and semantics of that building block .
2. Adornments
• Most elements in the UML have a unique an d direct graphical notation that provides a visual
representation of the most important aspects of the element.
3. Common Divisions
• In modeling object -oriented systems, There is the division of class and object.
• A class is an abstraction; an object is one concrete manifestation of that abstraction.

• Second, there is the separation of interface and implementation.

• An interface declares a contract, and an implementation represents one concrete realization of

that contract.

7
PSCMR CET (R20)
 Unit – II (Part 1)
Object Oriented Analysis and Design 8

4. Extensibility Mechanisms

The UML's extensibility mechanisms include:

• 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.
Represent with symbol << >>

• Tagged values: A tagged value extends the properties of a UML building block,
allowing you to create new information in that ele ment's specification.
Represent with {}
• Constraints: A constraint extends the semantics of a UML building block, allowing
you to add new rules or modify existing ones.
Represents with { }

UML Architecture
• The artifacts visualizing, specifying, constructing, and documenting a software -
intensive system demands viewed from a number of perspectives.
•
A system's architecture is perhaps the most important artifact that can be used to
ma nage these different viewpoints.
Architecture is the set of significant decisions about
• The organization of 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 behavioral elements into progressively larger
subsystems
• The architectural style that guides this organization: the static and dynamic elements and
their interfaces, their collaborations, and their composition
• Software architecture is not only concerned with structure and behavior, but also
with usage, functionality, performance, resilience, and reuse .

8
PSCMR CET (R20)
 Unit – II (Part 1)
Object Oriented Analysis and Design 9

Use case view

• It encompasses the use cases that describe the behavior of the system as seen by its
end users, analysts, and testers.
• This view doesn't really specify the organization of a software system.
 Static aspects - use case diagrams.
 Dynamic aspects- interaction diagrams, state chart diagrams, and activity
diagrams.

Modeling System’s Architecture

Design view
• It encompasses 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.
 Static aspects - class diagrams and object diagrams
 Dynamic aspects- interaction diagrams, state chart diagrams, and activity
diagrams.
Process view
• It encompasses 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.
 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
• It encompasses 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.
 Static aspects - component diagrams
 Dynamic aspects- interaction diagrams, state chart diagrams, and activity diagrams.

9
PSCMR CET (R20)
 Unit – II (Part 1)
Object Oriented Analysis and Design 10

Deployment view
• It encompasses 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.
 Static aspects - Deployment diagrams

 Dynamic aspects - interaction diagrams, state chart diagrams, and activity diagrams.

Software Development Life Cycle

• To get the most benefit from the UML, we should consider a process that i s
• Use case driven
• Architecture -centric
• Iterative and incremental
Use case driven
• Use cases are used as a primary artifact for establishing the desired behavior of
the system.
• It is used for verifying and validating the system's architecture, for testing, and
for communicating among the stakeholders of the project.
Architecture -centric
• Here a system's architecture is used as a primary artifact for conceptualizing,
constructing, managing, and evolving the system under development.
Iterative process
• It is one that involves managing a stream of executable releases.
Incremental process
• It is one that involves the continuous integration of the system's architecture to
produce these releases.
• Together, an iterative and incremental process is risk-driven .
This use case driven, architecture -centric, and iterative/ incremental process can be broken
into phases.

There are four phases in the software development life cycle:

1. Inception
• It is the first phase of the process, when the seed idea
for the development is brought up to the point .
2. Elaboration
• It 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.
• A system's requirements may range from general vision statements to precise evaluation
criteria .

10
PSCMR CET (R20)
 Unit – II (Part 1)
Object Oriented Analysis and Design 11

3. Construction
• It is the third phase of the process, when the software is brought from an
executable architectural baseline to being ready to be transitioned to the user
community.
• Here also, the system's requirements and especially its evaluation criteria are
constantly reexamined against the business needs of the project, and resources are
allocated as appropriate to actively attack risks to the project.
4. Transition
• It is the fourth phase of the process, when the software is turned into the hands of
the user community.
• Rarely does the software development process end here, for even during this phase,
the system is continuously improved, bugs are eradicated, and features that didn't
make an earlier release are added.

Software Development Life Cycle

11
PSCMR CET (R20)