You are on page 1of 55

UML:

An Introduction

Object Oriented Analysis and Design

Contents

Why model ?

Principles of modeling

What is UML ?

Conceptual Model of the UML


Building Blocks
Rules
Common Mechanisms

CDAC (Formerly NCST)

Introduction to UML

Object Oriented Analysis and Design

Why Model ?

Analyse the problem-domain


simplify reality
capture requirements
visualize the system in its entirety
specify the structure and/or behaviour of the
system

Design the solution


document the solution - in terms of its
structure, behaviour, etc.

CDAC (Formerly NCST)

Introduction to UML

Object Oriented Analysis and Design

Importance of Modeling

Models help us
to visualize a system as it is or as we want it
to be.
to specify the structure or behavior of a
system.
in providing a template that guides us in
constructing a system.
in providing documenting the decisions we
have made.

CS 3300 Object-

CDAC (Formerly NCST)

Object-Oriented

Introduction to UML

Object Oriented Analysis and Design

Principles of Modeling

Choose your model well - the choice of model profoundly


impacts the analysis of the problem and the design of the solution.

Every model may be expressed at different levels


of precision - the same model can be scaled up (or down) to
different granularities.

The best models are connected to reality - simplify


the model, but dont hide important details.

No single model suffices - every nontrivial system has


different dimensions to the problem and its solution.

CDAC (Formerly NCST)

Introduction to UML

Object Oriented Analysis and Design

Object-Oriented Modeling

Two most common ways in modeling software


systems are
Algorithmic
Procedures or functions

Object oriented
Objects or classes

CS 3300 Object-

CDAC (Formerly NCST)

Object-Oriented

Introduction to UML

Object Oriented Analysis and Design

What is UML ?

UML - Unified Modeling language

UML is a modeling language, not a methodology


or process

Fuses the concepts of the Booch, OMT, OOSE


methods

Developed by Grady Booch, James Rumbaugh


and Ivar Jacobson at Rational Software.

Accepted as a standard by the Object


Management Group (OMG), in 1997.

CDAC (Formerly NCST)

Introduction to UML

Object Oriented Analysis and Design

What is UML?

UML is a language for


Visualizing
Specifying
Constructing
Documenting

CS 3300 Object-

CDAC (Formerly NCST)

Object-Oriented

Introduction to UML

Object Oriented Analysis and Design

More on UML...
UML is a modeling language for visualising,
specifying, constructing and documenting the
artifacts of software systems.
Visualising - a picture is worth a thousand
words; a graphical notation articulates and
unambiguously communicates the overall view
of the system (problem-domain).

CDAC (Formerly NCST)

Introduction to UML

Object Oriented Analysis and Design

More on UML...
Specifying - UML provides the means to model
precisely, unambiguously and completely, the
system in question.

Constructing - models built with UML


have a design dimension to it; these are
language independent and can be
implemented in any programming language.

CDAC (Formerly NCST)

Introduction to UML

10

Object Oriented Analysis and Design

More on UML...
Documenting - every software
project involves a lot of documentation from the inception phase to the
deliverables.

Documentation is
(among others) for:

Requirements
Design
Tests

CDAC (Formerly NCST)

UML provides the


notations for
documenting some
of these artifacts

Introduction to UML

11

Object Oriented Analysis and Design

Conceptual Model of UML

Building Blocks

Things
Relationships
Diagrams

Rules

Common Mechanisms

Specifications
Adornments
Common Divisions
Extensibility Mechanisms

CDAC (Formerly NCST)

Introduction to UML

12

Object Oriented Analysis and Design

UML Building Blocks

Things

Structural
Behavioral
Grouping
Annotational

Relationships

Diagrams

Class Diagram
Object Diagram
Use Case Diagram
Behaviour Diagram
Implementation Diagram

Dependency
Association
Generalisation
Realization

CDAC (Formerly NCST)

Introduction to UML

13

Object Oriented Analysis and Design

Structural Things
The nouns of UML models; usually the static
parts of the system in question.

Class - an abstraction of a set of things in the problemdomain that have similar properties and/or functionality.
Notation:

customer

Interface - a collection of operations that specify the


services rendered by a class or component.
Notation:

CDAC (Formerly NCST)

Introduction to UML

14

Object Oriented Analysis and Design

Structural Things (contd.)

Collaboration - a collection of UML building blocks


(classes, interfaces, relationships) that work together to
provide some functionality within the system.
Notation:

Accounts
System

Use Case - an abstraction of a set of functions that the


system performs; a use case is realized by a collaboration.
Notation:

CDAC (Formerly NCST)

Process
Order
Introduction to UML

15

Object Oriented Analysis and Design

Structural Things (contd.)

Active Class - a class whose instance is an active object;


an active object is an object that owns a process or thread
(units of execution)
Notation:

eventManager

Component - a physical part (typically manifests itself as


a piece of software) of the system.
Notation:

CDAC (Formerly NCST)

DML_Parser.C

Introduction to UML

16

Object Oriented Analysis and Design

Structural Things (contd.)

Node - a physical element that exists at run-time and


represents a computational resource (typically, hardware
resources).

Notation:

CDAC (Formerly NCST)

PrintServer

Introduction to UML

17

Object Oriented Analysis and Design

Behavioral Things
The verbs of UML models; usually the dynamic
parts of the system in question.

Interaction - some behaviour constituted by messages


exchanged among objects; the exchange of messages is with a
view to achieving some purpose.
Notation:

CDAC (Formerly NCST)

Parse

Introduction to UML

18

Object Oriented Analysis and Design

Behavioral Things (contd.)

State machine - a behaviour that specifies the sequence


of states an object goes through, during its lifetime. A
state is a condition or situation during the lifetime of an
object during which it exhibits certain characteristics and/or
performs some function.
Notation:

CDAC (Formerly NCST)

Engine
Idling

Introduction to UML

19

Object Oriented Analysis and Design

Grouping Things
The organisational part of the UML model; provides a
higher level of abstraction (granularity).

Package - a general-purpose element that comprises UML


elements - structural, behavioral or even grouping things.
Packages are conceptual groupings of the system and need
not necessarily be implemented as cohesive software modules.
.

Notation:

CDAC (Formerly NCST)

Accounts
Department

Introduction to UML

20

Object Oriented Analysis and Design

Annotational Things
The explanatory part of the UML model; adds
information/meaning to the model elements.

Note - a graphical notation for attaching constraints and/or


comments to elements of the model.

Notation:

CDAC (Formerly NCST)

Parses userquery and builds


expression stack
(or invokes
ErrorHandler)

Introduction to UML

21

Object Oriented Analysis and Design

Relationships
Articulates the meaning of the links between things.

Dependency - a semantic relationship where a change in


one thing (the independent thing) causes a change in the
semantics of the other thing (the dependent thing).
Notation:
(arrow-head points to the independent thing)

Association - a structural relationship that describes the


connection between two things.
Notation:

CDAC (Formerly NCST)

Introduction to UML

22

Object Oriented Analysis and Design

Relationships (contd.)

Generalisation - a relationship between a general thing


(called parent or superclass) and a more specific kind of
that thing (called the child or subclass), such that the
latter can substitute the former.
Notation:
(arrow-head points to the superclass)

CDAC (Formerly NCST)

Introduction to UML

23

Object Oriented Analysis and Design

Relationships (contd.)

Realization - a semantic relationship between two things


wherein one specifies the behaviour to be carried out, and
the other carries out the behaviour.

a collaboration realizes a Use Case


the Use Case specifies the behaviour (functionality)
to be carried out (provided), and the collaboration
actually implements that behaviour.
Notation:

CDAC (Formerly NCST)

(arrow-head points to the thing being


realized)

Introduction to UML

24

Object Oriented Analysis and Design

Diagrams
The graphical presentation of the model. Represented
as a connected graph - vertices (things) connected by
arcs (relationships).
UML includes nine diagrams - each capturing a
different dimension of a software-system architecture.

Class Diagram
Object Diagram
Use Case Diagram
Sequence Diagram
Collaboration Diagram

CDAC (Formerly NCST)

Statechart Diagram
Activity Diagram
Component Diagram
Deployment Diagram

Introduction to UML

25

Object Oriented Analysis and Design

More on Diagrams...

Class Diagram - the most common diagram found in


OOAD, shows a set of classes, interfaces, collaborations and
their relationships. Models the static view of the system.

Object Diagram - a snapshot of a class diagram; models


the instances of things contained in a class diagram.

Use Case Diagram - shows a set of Use Cases (sets


of functionality performed by the system), the actors
(typically, people/systems that interact with this
system[problem-domain]) and their relationships. Models
WHAT the system is expected to do.

CDAC (Formerly NCST)

Introduction to UML

26

Object Oriented Analysis and Design

Class diagram example


StudentBody

Student
- firstName
: String
1

+ main (args :
String[])

100

- lastName : String
- homeAddress :
Address
- schoolAddress :
Address
+ toString() : String

Address

- streetAddress :
String
- city : String
- state : String
- zipCode : long
+ toString() : String
CDAC (Formerly NCST)

Introduction to UML

27

27

Object Oriented Analysis and Design

Object Diagram example

CDAC (Formerly NCST)

Introduction to UML

28

Object Oriented Analysis and Design

Use case example

CDAC (Formerly NCST)

Introduction to UML

29

Object Oriented Analysis and Design

More on Diagrams...

Sequence Diagram - models the flow of control by timeordering; depicts the interaction between various objects by
of messages passed, with a temporal dimension to it.

Collaboration Diagram - models the interaction


between objects, without the temporal dimension; merely
depicts the messages passed between objects and classes.

State chart Diagram - shows the different state


machines and the events that leads to each of these state
machines. State chart diagrams show the flow of control from
state to state.

CDAC (Formerly NCST)

Introduction to UML

30

Object Oriented Analysis and Design

Sequence Diagram

CDAC (Formerly NCST)

Introduction to UML

31

Object Oriented Analysis and Design

Ex. Collaboration Diagram

CDAC (Formerly NCST)

Introduction to UML

32

Object Oriented Analysis and Design

State chart Diagram Ex

CDAC (Formerly NCST)

Introduction to UML

33

Object Oriented Analysis and Design

More on Diagrams...

Activity Diagram - shows the flow from activity to


activity; an activity is an ongoing non-atomic execution
within a state machine.

Component Diagram - shows the physical packaging


of software in terms of components and the dependencies
between them.

Deployment Diagram - shows the configuration of the


processing nodes at run-time and the components that live on
them.

CDAC (Formerly NCST)

Introduction to UML

34

Object Oriented Analysis and Design

Activity Diagram: Example

CDAC (Formerly NCST)

Introduction to UML

35

COMPONENT DIAGRAM
EXAMPLE

Object Oriented Analysis and Design

CDAC (Formerly NCST)

Introduction to UML

36

Object Oriented Analysis and Design

Deployment diagram ex

CDAC (Formerly NCST)

Introduction to UML

37

Object Oriented Analysis and Design

Rules

Specify what a well-formed model should


look like.

The UML has semantic rules for


Names
Scope
Visibility
Integrity
Execution

CDAC (Formerly NCST)

Introduction to UML

38

Object Oriented Analysis and Design

UML Common Mechanisms

UML has four common mechanisms that are applied consistently,


in different contexts, throughout UML.

CDAC (Formerly NCST)

Introduction to UML

39/31

39

Object Oriented Analysis and Design

UML Common Mechanisms:


Specifications

Specifications are textual descriptions of the semantics of UML


elements.

CDAC (Formerly NCST)

Introduction to UML

40/31

40

Object Oriented Analysis and Design

UML Common Mechanisms:


Adornments

Adornments allow showing more information on UML elements.

CDAC (Formerly NCST)

Introduction to UML

41/31

41

Object Oriented Analysis and Design

Adornments
Adorn the model - i.e., enhance the model. Adds to
the meaning and/or semantics of the element to
which it pertains.
Notes are the mechanism provided by UML for
adorning a model:

graphical symbol to render constraints, comments, etc.

a note that renders only a comment has no semantic


impact on the element it is adorning; at most adds
meaning to it and/or provides guidelines for
implementation.

CDAC (Formerly NCST)

Introduction to UML

42

Object Oriented Analysis and Design

UML Common Mechanisms: Common


Divisions

Common divisions are ways of thinking about the world


(for modeling purposes)
Common divisions in UML are of two types:
Classifiers and instances [see Table 1.2 in the book]
Interface and implementation

CDAC (Formerly NCST)

Introduction to UML

43/31

43

Object Oriented Analysis and Design

Common Divisions

This is the second extension mechanism that is


provided to us by the UML. Common divisions
are used in order to distinguish between two
things that might appear to be quite similar, or
closely related to one another. There exist two
main common divisions:
Abstraction vs. Manifestation and Interface
vs. Implementation.
In the former, we mainly talk about the
distinction between a class and an object,where
the class is an abstraction and the object is a
clear manifestation of that class.

CDAC (Formerly NCST)

Introduction to UML

44

Object Oriented Analysis and Design

Contd.

Most UML building blocks have this kind of


class/object distinction, e.g. use case , use
case instance etc.
In the second common division interface vs.
implementation we say that an interface
declares some kind of contract, or agreement,
whereas an implementation represents one
concrete realisation of that contract. The
implementation is then responsible for carrying
out the interface.

CDAC (Formerly NCST)

Introduction to UML

45

Object Oriented Analysis and Design

UML Common Mechanisms:


Extensibility
There are three types of mechanisms that provide support for
UML extensibility.

CDAC (Formerly NCST)

Introduction to UML

46/31

46

Object Oriented Analysis and Design

Stereotypes

Used to create new building blocks from


existing blocks.

New building blocks are domain-specific.

A particular abstraction is marked as a


stereotype and this stereotype is then used at
other places in the model to denote the
associated abstraction.
Notation: metaclass

CDAC (Formerly NCST)

Introduction to UML

47

Object Oriented Analysis and Design

Tagged Values

Used to add to the information of the element


(not of its instances).

Stereotypes help create new building blocks;


tagged values help create new attributes.

Commonly used to specify information relevant


to code generation, configuration management,
etc.
Notation: {version=1.4}

CDAC (Formerly NCST)

Introduction to UML

48

Object Oriented Analysis and Design

Constraints

Used to create rules for the model.

Rules that impact the semantics of the model,


and specify conditions that must be met.

Can apply to any element in the model attributes of a class, relationship, etc.
Notation: { incomplete, disjoint }

CDAC (Formerly NCST)

Introduction to UML

49

Object Oriented Analysis and Design

ARCHITECTURE
Visualizing ,Specifying ,Constructing and
Documenting a software system demands that
the system can be viewed in different
perspectives.
Architecture is the set of significant decisions
about:
-The organisation of a software system
-The Selection of the structural elements and
their interfaces by which the system is
composed.
CDAC (Formerly NCST)

Introduction to UML

50

Object Oriented Analysis and Design

Architecture.

The system architecture is the organizational structure of the system,


including its decomposition into parts, their connectivity, interaction,
mechanisms and the guiding principles that inform the design of a system.
[Rumbaugh 1998]
There is a typical 4+1 views architecture of a system defined by UML:
Logical view, captures the vocabulary of the problem domain using classes and
objects
Process view, depicts the threads and processes of the system as active
classes
Implementation view, shows the physical code base of the system in terms of
components
Deployment view, models the physical deployment of components onto
computational nodes
Use case view, captures the requirements of the system using a set of use
cases. This is the view +1 to which all other views connect.
CDAC (Formerly NCST)

Introduction to UML

51/31

51

Object Oriented Analysis and Design

.Architecture
The 4 +1 views architecture, Fig. 1.13 [Arlow & Neustadt 2005]

CDAC (Formerly NCST)

Introduction to UML

52/31

52

Object Oriented Analysis and Design

Software Development Life Cycle

Should consider the process as:


Use case and risk driven

Architecture centric

Iterative and incremental

Each iteration contains all the elements of a regular software


development project: planning, analysis, design, construction,
integration, testing, internal or external release

CDAC (Formerly NCST)

Introduction to UML

53/31

53

Object Oriented Analysis and Design

SDLC

CDAC (Formerly NCST)

Introduction to UML

54/31

54

Object Oriented Analysis and Design

SDLC: Details on Phases.

Each of the four phases of UP (inception, elaboration,


construction, transition) has:
A goal
A focus of activity
One or more core workflows
A milestone, with a number of conditions of satisfaction

CDAC (Formerly NCST)

Introduction to UML

55/31

55