1. UML: An Introduction

2. Contents Why model ? Principles of modeling What is UML ?
Conceptual Model of the UML
Building Blocks
Rules
Common Mechanisms

3. 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.

4. Principles of Modeling
(C) National Centre for Software Technology
April 16, 2017
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 don’t hide important details.
No single model suffices - every nontrivial system has different dimensions to the problem and its solution.
Choose your model well:
ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution
OOAD will yield object-centered solution
Granularities:
The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times.
Connected to reality:
very often it helps to make simplifying assumptions, but in "simplifying" one has to do judiciously
e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others
No single model suffices:
Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all.
Object Oriented Analysis and Design

5. (C) National Centre for Software Technology
April 16, 2017
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.
Choose your model well:
ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution
OOAD will yield object-centered solution
Granularities:
The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times.
Connected to reality:
very often it helps to make simplifying assumptions, but in "simplifying" one has to do judiciously
e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others
No single model suffices:
Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all.
Object Oriented Analysis and Design

6. (C) National Centre for Software Technology
April 16, 2017
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).
Choose your model well:
ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution
OOAD will yield object-centered solution
Granularities:
The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times.
Connected to reality:
very often it helps to make simplifying assumptions, but in "sampling" one has to do judiciously
e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others
No single model suffices:
Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all.
Object Oriented Analysis and Design

7. (C) National Centre for Software Technology
April 16, 2017
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.
Choose your model well:
ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution
OOAD will yield object-centered solution
Granularities:
The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times.
Connected to reality:
very often it helps to make simplifying assumptions, but in "sampling" one has to do judiciously
e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others
No single model suffices:
Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all.
Object Oriented Analysis and Design

8. (C) National Centre for Software Technology
April 16, 2017
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:
Choose your model well:
ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution
OOAD will yield object-centered solution
Granularities:
The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times.
Connected to reality:
very often it helps to make simplifying assumptions, but in "sampling" one has to do judiciously
e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others
No single model suffices:
Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all.
Requirements
Design
Tests
Object Oriented Analysis and Design

9. Conceptual Model of UML
(C) National Centre for Software Technology
April 16, 2017
Conceptual Model of UML
Building Blocks
Rules
Common Mechanisms
Things
Relationships
Diagrams
A modeling language is typically characterised by two aspects - the elements of the language (and the semantics that those elements embody) and the (graphical) notation for those elements.
Specifications
Adornments
Common Divisions
Extensibility Mechanisms
Object Oriented Analysis and Design

10. (C) National Centre for Software Technology
April 16, 2017
UML Building Blocks
Things
Relationships
Diagrams
Structural
Behavioral
Grouping
Annotational
Class Diagram
Object Diagram
Use Case Diagram
Behaviour Diagram
Implementation Diagram
Dependency
Association
Generalisation
Realization
Choose your model well:
ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution
OOAD will yield object-centered solution
Granularities:
The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times.
Connected to reality:
very often it helps to make simplifying assumptions, but in "sampling" one has to do judiciously
e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others
No single model suffices:
Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all.
Object Oriented Analysis and Design

11. (C) National Centre for Software Technology
April 16, 2017
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 problem-domain that have similar properties and/or functionality.
Notation:
customer
Class : typically an abstraction of the STRUCTURAL things of the system (problem-domain)
Use Case : typically an abstraction of the BEHAVIOURAL things of the system (problem-domain)
Interface - a collection of operations that specify the services rendered by a class or component.
Notation:
Object Oriented Analysis and Design

12. Structural Things (contd.)
(C) National Centre for Software Technology
April 16, 2017
Structural Things (contd.)
Collaboration - a collection of UML building blocks (classes, interfaces, relationships) that work together to provide some functionality within the system.
Accounts System
Notation:
Use Case - an abstraction of a set of functions that the system performs; a use case is “realized” by a collaboration.
Class : typically an abstraction of the STRUCTURAL things of the system (problem-domain)
Use Case : typically an abstraction of the BEHAVIOURAL things of the system (problem-domain)
Process Order
Notation:
Object Oriented Analysis and Design

13. Structural Things (contd.)
(C) National Centre for Software Technology
April 16, 2017
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.
Component : a physical part of the system - typically a piece of software - like a library, an executable or even an ordinary document.
Notation:
DML_Parser.C
Object Oriented Analysis and Design

14. Structural Things (contd.)
(C) National Centre for Software Technology
April 16, 2017
Structural Things (contd.)
Node - a physical element that exists at run-time and represents a computational resource (typically, hardware resources).
PrintServer
Notation:
Component : a physical part of the system - typically a piece of software - like a library, an executable or even an ordinary document.
Object Oriented Analysis and Design

15. (C) National Centre for Software Technology
April 16, 2017
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.
Parse
Notation:
Object Oriented Analysis and Design

16. Behavioral Things (contd.)
(C) National Centre for Software Technology
April 16, 2017
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.
Engine
Idling
Notation:
State machine diagrams are especially relevant if the model pertains to/involves systems like digital/logic circuits where an element changes its "state" due to some input
Object Oriented Analysis and Design

17. (C) National Centre for Software Technology
April 16, 2017
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. .
Accounts
Department
Notation:
Object Oriented Analysis and Design

18. (C) National Centre for Software Technology
April 16, 2017
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:
Object Oriented Analysis and Design

19. (C) National Centre for Software Technology
April 16, 2017
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)
Class : typically an abstraction of the STRUCTURAL things of the system (problem-domain)
Use Case : typically an abstraction of the BEHAVIOURAL things of the system (problem-domain)
Association - a structural relationship that describes the connection between two things.
Notation:
Object Oriented Analysis and Design

20. Relationships (contd.)
(C) National Centre for Software Technology
April 16, 2017
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)
Class : typically an abstraction of the STRUCTURAL things of the system (problem-domain)
Use Case : typically an abstraction of the BEHAVIOURAL things of the system (problem-domain)
Object Oriented Analysis and Design

21. Relationships (contd.)
(C) National Centre for Software Technology
April 16, 2017
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.
One generally talks of a component or a class "realizing an interface".
What this means, is that the component or class in question guarantees to provide or perform or carry out the functionality/operation that the interface announces it will be carrying out.
Notation:
(arrow-head points to the thing being realized)
Object Oriented Analysis and Design

22. (C) National Centre for Software Technology
April 16, 2017
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
Sequence Diagrams and Collaboration Diagrams are both known as "Interaction Diagrams".
Object Oriented Analysis and Design

23. (C) National Centre for Software Technology
April 16, 2017
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.
Object Diagram : shows a set of OBJECTS and their relationships at a particular point of time.
Object Oriented Analysis and Design

24. (C) National Centre for Software Technology
April 16, 2017
More on Diagrams...
Sequence Diagram - models the flow of control by time-ordering; 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.
Object Diagram : shows a set of OBJECTS and their relationships at a particular point of time.
Object Oriented Analysis and Design

25. (C) National Centre for Software Technology
April 16, 2017
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.
Object Diagram : shows a set of OBJECTS and their relationships at a particular point of time.
Object Oriented Analysis and Design

26. (C) National Centre for Software Technology
April 16, 2017
Dimensions...
. . .of Software Architecture
Structural
View
Implementation
View
Class Diagrams
Object Diagrams
Component Diagrams
User View
Use Case
Diagrams
Sequence Diagrams
Collaboration Diagrams
Statechart Diagrams
Activity Diagrams
Object Diagram : shows a set of OBJECTS and their relationships at a particular point of time.
Deployment Diagrams
Behavioral
View
Environment
View
Object Oriented Analysis and Design

27. (C) National Centre for Software Technology
April 16, 2017
Rules
Specify what a well-formed model should look like.
The UML has semantic rules for
Names
Scope
Visibility
Integrity
Execution
Choose your model well:
ER Model is best-suited for modeling databases (DB Design). SSAD will yield an algorithmic-centered solution
OOAD will yield object-centered solution
Granularities:
The bird's-eye view is as important as the fine-grained view. Different groups of interested parties will employ/use different views at different times.
Connected to reality:
very often it helps to make simplifying assumptions, but in "sampling" one has to do judiciously
e.g. assuming a dedicated telephone link may be o.k. in some cases, disastrous in others
No single model suffices:
Analysis and Designs have several dimensions - structural, temporal, behavioral - a single model hardly ever suffices to capture them all.
Object Oriented Analysis and Design

28. (C) National Centre for Software Technology
April 16, 2017
Common Mechanisms
Mechanisms/elements that apply consistently throughout the language:
Specifications
Adornments
Common Divisions
Extensibility Mechanisms
(Notes)
Specifications and Common Divisions are important, but they are an inherent characteristic of the UML.
Stereotypes
Tagged values
Constraints
Object Oriented Analysis and Design

29. (C) National Centre for Software Technology
April 16, 2017
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.
Sequence Diagrams and Collaboration Diagrams are both known as "Interaction Diagrams".
Object Oriented Analysis and Design

30. (C) National Centre for Software Technology
April 16, 2017
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.
Sequence Diagrams and Collaboration Diagrams are both known as "Interaction Diagrams".
Notation:
«metaclass»
Object Oriented Analysis and Design

31. (C) National Centre for Software Technology
April 16, 2017
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.
Sequence Diagrams and Collaboration Diagrams are both known as "Interaction Diagrams".
Notation:
{version=1.4}
Object Oriented Analysis and Design

32. (C) National Centre for Software Technology
April 16, 2017
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.
Sequence Diagrams and Collaboration Diagrams are both known as "Interaction Diagrams".
Notation:
{ incomplete, disjoint }
Object Oriented Analysis and Design

33. 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

34. Summary
UML (Unified Modeling Language) is a language that helps analyse and design solutions for software-intensive 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.

35. 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.

36. 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.

37. 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 system’s 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.

38. 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.

39. References  The Unified Modeling Language User Guide  UML Distilled
Grady Booch, James Rumbaugh, Ivar Jacobson
Addison-Wesley (International Student Edition)
 UML Distilled
Martin Fowler (with Kendall Scott)
Addison-Wesley