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 the solution document the solution - in terms of its structure, behaviour, etc.
Introduction to UML
3

Design

CDAC (Formerly NCST)

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

What is UML ?
UML

- Unified Modeling language

UML

is a modeling language, not a methodology or process

the concepts of the Booch, OMT, OOSE methods by Grady Booch, James Rumbaugh and Ivar Jacobson at Rational Software. as a standard by the Object Management Group (OMG), in 1997.
Introduction to UML
5

Fuses

Developed Accepted

CDAC (Formerly NCST)

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

Object Oriented Analysis and Design

More on UML...
Documenting - every software
project involves a lot of documentation from the inception phase to the deliverables. UML provides the notations for documenting some of these artifacts

Documentation is (among others) for:

Requirements Design Tests

CDAC (Formerly NCST)

Introduction to UML

Object Oriented Analysis and Design

Conceptual Model of UML

Building Blocks

Things Relationships Diagrams

Rules Common Mechanisms

Specifications Adornments Common Divisions Extensibility Mechanisms

Introduction to UML
9

CDAC (Formerly NCST)

Object Oriented Analysis and Design

UML Building Blocks

Things

Diagrams

Structural Behavioral Grouping Annotational

Relationships

Class Diagram Object Diagram Use Case Diagram Behaviour Diagram Implementation Diagram

Dependency Association Generalisation Realization

CDAC (Formerly NCST)

Introduction to UML

10

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

11

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: Process Order
Introduction to UML
12

CDAC (Formerly NCST)

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: DML_Parser.C

CDAC (Formerly NCST)

Introduction to UML

13

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). PrintServer

Notation:

CDAC (Formerly NCST)

Introduction to UML

14

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: Parse

CDAC (Formerly NCST)

Introduction to UML

15

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: Engine Idling

CDAC (Formerly NCST)

Introduction to UML

16

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:

Accounts Department

CDAC (Formerly NCST)

Introduction to UML

17

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. Parses user-query and builds expression stack (or invokes ErrorHandler)

Notation:

CDAC (Formerly NCST)

Introduction to UML

18

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

19

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

20

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:
(arrow-head points to the thing being realized)
CDAC (Formerly NCST)

Introduction to UML

21

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

Statechart Diagram Activity Diagram Component Diagram Deployment Diagram

CDAC (Formerly NCST)

Introduction to UML

22

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

23

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.

Statechart Diagram - shows the different state machines

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

CDAC (Formerly NCST)

Introduction to UML

24

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

25

Object Oriented Analysis and Design

Dimensions...
. . .of Software Architecture
Structural Implementation View View Class Diagrams Object Diagrams Component Diagrams

User View
Use Case Diagrams

Sequence Diagrams Deployment Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams Behavioral Environment View View
CDAC (Formerly NCST)

Introduction to UML

26

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

27

Object Oriented Analysis and Design

Common Mechanisms

Mechanisms/elements that apply consistently throughout the language: Specifications Adornments (Notes) Common Divisions Extensibility Mechanisms Stereotypes Tagged values Constraints

CDAC (Formerly NCST)

Introduction to UML

28

Object Oriented Analysis and Design

Specifications

The UML is more 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. For example, behind a class icon is a specification that provides the full set of attributes, operations (including their full signatures), and behaviors that the class embodies; visually, that class icon might only show a small part of this specification. Furthermore, there might be another view of that class that presents a completely different set of parts yet is still consistent with the class's underlying specification. You use the UML's graphical notation to visualize a system; you use the UML's specification to state the system's details. Given this split, it's possible to build up a model incrementally by drawing diagrams and then adding semantics to the model's specifications, or directly by creating a specification, perhaps by reverse engineering an existing system, and then creating diagrams that are projections into those specifications. The UML's specifications provide a semantic backplane that contains all the parts of all the models of a system, each part related to one another in a consistent fashion. The UML's diagrams are thus simply visual projections into that backplane, each diagram revealing a specific interesting aspect of the system.

CDAC (Formerly NCST)

Introduction to UML

29

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.
Introduction to UML
30

CDAC (Formerly NCST)

Object Oriented Analysis and Design

Adornments
shows a class, adorned to indicate that it is an abstract class with two public, one protected, and one private operation.

CDAC (Formerly NCST)

Introduction to UML

31

Object Oriented Analysis and Design

Common Divisions

In modeling object-oriented systems, the world often gets divided in several ways. First, there is the division of class and object. A class is an abstraction; an object is one concrete manifestation of that abstraction. In the UML, you can model classes as well as objects, Graphically, the UML distinguishes an object by using the same symbol as its class and then simply underlying the object's name.

CDAC (Formerly NCST)

Introduction to UML

32

Object Oriented Analysis and Design

Common Divisions
In

this figure, there is one class, named Customer, together with three objects: Jan (which is marked explicitly as being a Customer object), :Customer (an anonymous Customer object), and Elyse (which in its specification is marked as being a kind of Customer object, although it's not shown explicitly here).

CDAC (Formerly NCST)

Introduction to UML

33

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

34

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

35

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

36

Object Oriented Analysis and Design

Constraints

CDAC (Formerly NCST)

Introduction to UML

37

Object Oriented Analysis and Design

Summary

Modeling captures the system in its entirety, along with the different dimensions of its complexity. Facilitates quick and efficient analysis and design and helps communicate the overall system architecture unambiguously.

Principles of modeling lay down that: model must be chosen well model should encapsulate different granularities models can make simplifying assumptions, but not hide important facts no single model can capture all dimensions of the complexity
Introduction to UML
38

CDAC (Formerly NCST)

Object Oriented Analysis and Design

Summary

UML (Unified Modeling Language) is a language that helps analyse and design solutions for softwareintensive systems Developed by Booch, Rumbaugh and Jacobson at Rational Software; subsequently adopted as an open standard by the Object Management Group in 1997. UML is a modeling language for visualising, specifying, constructing and documenting the artifacts of a software system. It is a modeling language and not a methodology or a process.
Introduction to UML
39

CDAC (Formerly NCST)

Object Oriented Analysis and Design

Summary

The conceptual model of the UML comprises the Building Blocks of UML, its Rules and certain Common Mechanisms that are applicable across the entire language. The Building Blocks comprise Things, Relationships and Diagrams. Things are of grouped into 4 categories: structural things, behavioral things, grouping things and annotational things.

CDAC (Formerly NCST)

Introduction to UML

40

Object Oriented Analysis and Design

Summary

Structural things describe the static part of the model and are of seven types: class, interface, collaboration, use case, active class, component, node. Behavioral things describe the dynamic part of the model and are of two types: interaction and state machine.

Packages are included under Grouping things, and Notes under Annotational things
Relationships link things to each other and are of four types: Dependency, Association, Generalisation and Realization.
Introduction to UML
41

CDAC (Formerly NCST)

Object Oriented Analysis and Design

Summary

Diagrams are essentially connected graphs - a set of vertices (things) connected by arcs (relationships). There are several types of diagrams, each one capturing a different dimension of the systems complexity. Diagrams are of nine types: Class Diagram, Object Diagram, Use Case Diagram, Sequence Diagram, Collaboration Diagram, Statechart Diagram, Activity Diagram, Implementation Diagram, Deployment Diagram. The UML has semantic rules for Names of classifiers, Scope of these names, Visibility of these names, and the Integrity and Execution of the model.

CDAC (Formerly NCST)

Introduction to UML

42

Object Oriented Analysis and Design

Summary

Certain common mechanisms apply uniformly across the model. There are four such mechanisms: Specifications, Common Divisions, Adornments, Extensibility Mechanisms. Notes are the most common adornments used, that add to the meaning of a classifier. Extensibility mechanisms include Stereotypes, Tagged values and constraints.

CDAC (Formerly NCST)

Introduction to UML

43

References
The Unified Modeling Language User Guide
Grady Booch, James Rumbaugh, Ivar Jacobson Addison-Wesley (International Student Edition)

UML Distilled
Martin Fowler (with Kendall Scott) Addison-Wesley