s Introduction

Object Oriented Modelling
UNIT-1 Introduction to UML
Why we model:
Modeling is a central part of all the activities that leads to the
deployment of good software. Models are built to
 Communicate the desired structure and behavior of our system.
 Visualize and control the system's architecture.
 Better understand the system we are building, often exposing
opportunities for simplification and reuse.
 Manage risk.
Improtance of Modeling:
What is Model:
 A model is a simplification of reality.
 It provides the blueprints of the system.
 Models may include detailed plans, as well as more general plans.
 A good model includes those elements that have broad effect and
omits those minor elements that are not relevant to the given level of
abstraction.
 A model may be structural, emphasizing the organization of the
system, or it may be behavioral, emphasizing the dynamics of the
system
Models are built to better understand the system we are developing.
Four aims achieved through modeling:

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.
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“
 Formal and informal modelling
 These informal models are often ad hoc and do not provide a
common language that can easily be shared with others.
 A common language of blueprints for the different industries
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.
OR
Choose your models well
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
Object-Oriented Modeling:
In software, there are several ways to approach a model. The two most
common ways are from
1. An algorithmic perspective
It is traditional view.
Main building block-------Procedure or function
Control and decomposition of larger algorithms into smaller
2. An object-oriented perspective.
It is contemporary view
Main building block-------Object or class
Introduction the UML:
 Unified Modeling Language (UML) is a general purpose modeling
language.
 The main aim of UML is to define a standard way to visualize the way a
system has been designed. It is quite similar to blueprints used in other
fields of engineering.
 UML is not a programming language, it is a visual language.
 We use UML diagrams to portray the behavior and structure of a system.
 UML helps software engineers, businessmen and system architects with
modeling, design and analysis.
 The Object Management Group (OMG) adopted Unified Modeling
Language as a standard in 1997.
 Its been managed by OMG ever since. International Organization for
Standardization (ISO) published UML as an approved standard in 2005.
UML has been revised over the years and is reviewed periodically.
Introduction the UML:
 A modeling language is a language whose vocabulary and rules focus
on the conceptual and physical representation of a system
 The Unified Modeling Language (UML) is a standard language for
writing software blueprints.
 The UML may be used to
1. Visualize
2. Specify
3. Construct
4. Document the artifacts of a software intensive system
A Conceptual Model of the UML:
Three major elements:
1. The UML's basic building blocks
2. The rules that dictate how those building blocks may be put together.
3. Common mechanisms that apply throughout the UML.
Building Blocks of the UML:
The vocabulary of the UML has three kinds of building blocks:
1. Things
2. Relationships
3. Diagrams
Things in the UML
There are four kinds of things in the UML:
1. Structural things -----------nouns of UML models
2. Behavioral things --------- verbs of a model
3. Grouping things------------ organizational parts
4. Annotational things--------- to capture remarks, comments
Structural Things:
 These are the static parts of a model, representing elements that are
either conceptual or physical.
 There are seven kinds of structural things.
1. Classes
2. Interface
3. Collaboration
4. Use case
5. Active class
6. Component
7. Node
1.Class represents a set of objects having similar responsibilities.
2.Interface − Interface defines a set of operations, which specify the

responsibility of a class
3.Collaboration −Collaboration defines an interaction between elements

4.Use case −Use case represents a set of actions performed by a system
for a specific goal.
5.Component −Component describes the physical and replaceable part

of a system and provides the realization of a set of interfaces.
6. Node − A node can be defined as a physical element that exists at run

time.
7.Active class: A class whose objects own one or more processes or

threads and therefore can initiate control activity.
 Active classes, components, and nodes are all class-like, meaning they
also describe a set of objects that share the same attributes,
operations, relationships, and semantics.
 These three are different enough and are necessary for modeling
certain aspects of an object-oriented system, and so they warrant
special treatment
There are also variations, such as

 Kinds of classes----actors, signals, and utilities
 Kinds of active classes------ processes and threads
 Kinds of components-----applications, documents, files, libraries,
pages, and tables
Behavioral Things
Behavioral things are the dynamic parts of UML models.
These are the verbs of a model, representing behavior over time and
space. There are two kinds of behavioral things
1.Interaction: Interaction is defined as a behavior that consists of a
group of messages exchanged among elements to accomplish a specific
task.
2.State machine:It defines the sequence of states an object goes through

in response to events. Events are external factors responsible for state
change.
Grouping Things:
 Grouping things are the organizational parts of UML models.
 These are the boxes into which a model can be decomposed.
 One primary kind of grouping thing, namely, packages.
 A package is a general-purpose mechanism for organizing elements
into groups.
 Structural things, behavioral things, and other grouping things may be
placed in a package.
 Unlike components, a package is purely conceptual which exists only
at development time.
Annotational things:
 A mechanism to capture remarks, descriptions, and comments of UML
model elements.
 A note is used to render comments, constraints, etc. of an UML element.
Relationship
Relationship shows how the elements are associated with each other.
This association describes the functionality of an application.
There are four kinds of relationships
1. Dependency
2. Association
3. Generalization
4. Realization
1. Dependency
Dependency is a relationship between two things in which change in one
element also affects the other.
2. Association
Association is a set of links that connects the elements of a UML model.
It also describes how many objects are taking part in that relationship.
3. Generalization
Generalization can be defined as a relationship which connects a
specialized element with a generalized element. It describes the
inheritance relationship in the world of objects.
4. Realization
Realization can be defined as a relationship in which two elements are
connected. One element describes some responsibility, which is not
implemented and the other one implements them. This relationship exists
in case of interfaces.
Diagrams in the UML
 A diagram is the graphical presentation of a set of elements,
rendered as a connected graph of vertices (things) and arcs
(relationships).
 Diagrams are drawn to visualize a system from different
perspectives, so a diagram is a projection into a system.
 The UML includes nine diagrams:
1. Class diagram 6. Statechart diagram
2. Object diagram 7. Activity diagram
3. Use case diagram 8. Component diagram
4. Sequence diagram 9. Deployment diagram
5. Collaboration diagram
Class diagram
 It shows a set of classes, interfaces, and collaborations and their
relationships.
 Most common diagram.
 It address the static design view of a system.
 It include active classes address the static process view of a system.
Object diagram
 It shows a set of objects and their relationships.
 Object diagrams represent static snapshots of instances of the things
found in class diagrams.
 These diagrams address the static design view or static process view
of a system as do class diagrams, but from the perspective of real or
prototypical cases
Use case diagram
 It shows a set of use cases 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 important in organizing and modeling the
behaviors of a system.
Sequence diagrams and Collaboration diagrams
 Kinds of interaction diagrams.
 An interaction, consisting of a set of objects and their relationships,
including the messages that may be dispatched among them.
 Interaction diagrams address the dynamic view of a system.
 A sequence diagram is an interaction diagram that emphasizes the
time-ordering of messages.
 A collaboration diagram emphasizes the structural organization of the
objects that send and receive messages.
 Sequence diagrams and collaboration diagrams are isomorphic,
meaning that you can take one and transform it into the other.
Statechart diagram
 It shows a state machine, consisting of states, transitions, events, and
activities.
 Statechart diagrams address the dynamic view of a system.
 They are important in modeling the behavior of an interface, class, or
collaboration.
 It emphasize the event-ordered behavior of an object, which is
especially useful in modeling reactive systems.
Activity diagram
 It is a special kind of a statechart diagram that shows the flow from
activity to activity within a system.
 Activity diagrams address the dynamic view of a system.
 They are important in modeling the function of a system and
emphasize the flow of control among objects.
Component diagram
 It shows the organizations and dependencies among a set of
components.
 Component diagrams address the static implementation view of a
system.
 They are related to class diagrams in that a component typically maps
to one or more classes, interfaces, or collaborations
Deployment diagram
 It shows the configuration of run-time processing nodes and the
components that live on them.
 Deployment diagrams address the static deployment view of an
architecture.
 They are related to component diagrams in that a node encloses one or
more components.
Structural Modeling
 Class diagram
 Object diagram
Behavioral Modeling
 Interaction diagrams
 Use case diagram
 Activity diagram
 State chart diagram
Architectural Modeling
 Component diagram
 Deployment diagram
Rules of the UML
 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 related models.
The UML has semantic rules for
1. Names: What you can call things, relationships and diagrams
2. Scope: The context that gives specific meaning to a name
3. Visibility: How those names can be seen and used by others
4. Integrity: How things properly and consistently relate to one another
5. Execution: What it means to run or simulate a dynamic model
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

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
Adornments
Common divisions
a. Division of class and object.
Every building block in the UML has this same kind of
class/object dichotomy
b. The separation of interface and implementation

Extensibility Mechanisms (Advanced structural notation in UML)
The UML's extensibility mechanisms include

 Stereotypes
 Tagged value
 Constraint
Architecture
Visualizing, specifying, constructing, and documenting a software-

intensive system demands that the system be viewed from a number of
perspectives.
Architecture is the set of significant decisions 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 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
The use case view of a system
 Holds the use cases that describe the behavior of the system as seen
by its end users, analysts, and testers.
 It specifies the forces that shape the system's architecture.
 With the UML,
 The static aspects of this view are captured in
Use case diagrams
 The dynamic aspects of this view are captured in
Interaction diagrams
Statechart diagrams
Activity diagrams
The design view of a system
 Holds 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.
 With the UML,
Class diagrams and Object diagrams
Interaction diagrams, statechart diagrams, and activity
diagrams.
The process view of a system
 Holds 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.
 With the UML,
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.
The implementation view of a system
 Holds the components and files that are used to assemble and release
the physical system.
 This view addresses the configuration management of the system's
releases, made up of independent components and files that can be
assembled to produce a running system.
 With the UML,
 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
The deployment view of a system
 Holds 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.
 With the UML,
deployment diagrams
interaction diagrams, statechart diagrams, and activity diagrams.
UNIT-1 Architecture
Encompasses(Hol Addresses Static aspects Dynamic aspects
ds)
Use case view use cases organization use case diagrams interaction,
statechart,activity
diagrams
Design view classes, functional class diagrams, interaction,

interfaces, and requirements object diagrams statechart,activity
collaborations diagrams
Process view threads and performance, class diagrams, interaction,

processes scalability, and object diagrams statechart,activity
throughput diagrams
Implementation components and configuration component interaction,

view files management diagrams statechart,activity
diagrams
Deployment view Nodes distribution, deployment interaction,

delivery, and diagrams statechart,activity
installation diagrams
Software Development Life Cycle
 The UML is process-independent.
 To get most benefit from the UML, consider a process that is
 Use case driven (behavior of the system, for verifying and validating the
system's architecture, for testing, and for communicating among the
stakeholders of the project.)
 Architecture-centric(conceptualizing, constructing, managing, and

evolving the system under development)
 Iterative and incremental (Risk-driven)

 Process can be broken into phases

 A phase is the span of time between two major milestones of the
process
 There are four phases in the software development life cycle:
1. Inception
2. Elaboration
3. Construction
4. Transition.
Workflows are plotted against these phases, showing their varying degrees of
focus over time
1. Inception
 Here, the seed idea for the development is brought up to the point of
being, internally, sufficiently well-founded for entering into the
elaboration phase
2. Elaboration
 Here the product vision and its architecture are defined.
 The system's requirements are articulated, prioritized, and baselined.
 A system's requirements may range from general vision statements to
precise evaluation criteria.
 Each specifying particular functional or nonfunctional behavior and
each providing a basis for testing.
3.Construction
 Here 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 its evaluation criteria are
reexamined against the business needs of the project, and resources
are allocated appropriately to attack risks to the project.
4. Transition
 Here 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.
Iteration
• One element that distinguishes this process and that cuts across all
four phases is an iteration.
• An iteration is a distinct set of activities, with a baselined plan and
evaluation criteria that result in a release, either internal or external.
• Means that the SDLC can be characterized as involving a continuous
stream of executable releases of the system's architecture.

s Introduction

Uploaded by

Copyright:

Available Formats

s Introduction

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

s Introduction

Uploaded by

Copyright:

Available Formats

Object Oriented Modelling

UNIT-1 Introduction to UML

Models are built to better understand the system we are developing.

Four aims achieved through modeling:

We build models of complex systems because we cannot comprehend

1. The choice of what models to create has a profound

2. Every model may be expressed at different levels of

3. The best models are connected to reality.

4. No single model is sufficient. Every nontrivial

2.Interface − Interface defines a set of operations, which specify the

3.Collaboration −Collaboration defines an interaction between elements

5.Component −Component describes the physical and replaceable part

6. Node − A node can be defined as a physical element that exists at run

7.Active class: A class whose objects own one or more processes or

There are also variations, such as

2.State machine:It defines the sequence of states an object goes through

Elided: Certain elements are hidden to simplify the view

Common Mechanisms in the UML

b. The separation of interface and implementation

The UML's extensibility mechanisms include

Visualizing, specifying, constructing, and documenting a software-

 The organization of a software system

 Holds the classes, interfaces, and collaborations that form the

The process view of a system

Design view classes, functional class diagrams, interaction,

Process view threads and performance, class diagrams, interaction,

Implementation components and configuration component interaction,

Deployment view Nodes distribution, deployment interaction,

 To get most benefit from the UML, consider a process that is

 Architecture-centric(conceptualizing, constructing, managing, and

 Iterative and incremental (Risk-driven)

 Process can be broken into phases

 Here the software is brought from an executable architectural baseline

You might also like