UML

11/10/15 Winlex Ltd. 1
Rational Unified Process
and
Unified Modelling Language
Vinil Gupta

Winlex Ltd. 211/10/15
UML History
 Grady Booch – methodology
 Ivar Jacobson – methodology *
 Jim Rumbaugh – Object Modelling
Techniques
 Many others

Why UML
 Provides visual syntax throughout SDLC
 Suitable for most applications and is
platform neutral
 Provides excellent support for pure OO
languages, hybrid OO languages and non-
OO languages.
 Supports UP for OO systems and other
engineering processes

Objects and UML
 UML models the world as system of
interacting objects
 An Object is a cohesive cluster of data
and function
 Two aspect of UML:
1. Static Structure
2. Dynamic Behaviour

UML Structure
1. Building Blocks – basic modelling
elements, relationships and diagrams
2. Common Mechanism – way of achieving
specific goal
3. Architect – view of system architecture

1. Building Blocks
 Things – modelling elements themselves
 Relationship – specifies how things are
semantically related
 Diagrams – view into models; collection of
things that tells a story about the software
system; how it will do something

1.Things
In UML modelling elements are called things
 Structured things – class, interface,
collaboration, use case, active class,
component, node
 Behaviour things – interactions, state machines
 Group things – package of semantically related
modelling elements
 Annotational things – ad hoc info; yellow sticker

2.Relationship
 Description of a set of link
between objects
 A change to a thing affects the
semantics of a dependent thing
 One element is a specialisation
of another; substituted more
general element
 One classifier specifies a
contract that the other classifier
guarantees to carry out

3. Diagrams
 Diagrams contains things. Things can be
deleted from diagram but not from model
 Diagrams are only views into the model
and not the model itself
 There are a total of nine different UML
diagrams (i) Static Model; (ii) Dynamic
Model

3.Diagrams
 Static Model – System structure
1. Class diagram
2. Component Diagrams
3. Deployment Diagram

3.Diagrams
 Dynamic Model – System behaviour
1. Object diagram
2. Use Case diagram
3. Sequence diagram
4. Collaboration diagram
5. Statechart diagram
6. Activity diagram

UML Common Mechanism
UML has four common mechanism
1. Specifications
2. Adornments
3. Common divisions
4. Extensibility mechanism

1.Specification
Specifications are the meat of the UML model.
They provide the semantic backplane of the
model. UML model has at least two dimensions
1. Graphic dimensions – diagram
2. Textural dimensions – specifications textual
descriptions of the semantics of an element

1.Specification
UML models may be:
 Elided – some elements from diagrams to simplify the
view
 Incomplete – some elements may be missing entirely
 Inconsistent – model may contain contradictions

2.Adornments
A feature of UML that allows a symbol to every
modelling element, to which number of
adornments

3.Common Division
Common division describe particular way of
thinking about world. Two common UML
divisions are:
1. Classifier and instance
• Classifier – an abstract notion e.g. a type of bank
account
• Instance – a concrete thing e.g. my bank account

3.Common Division
1. Classifier and Instance – In UML an instance
usually has the same icon as the corresponding
classifier, but for instance the name on the icon
is underlined

3.Common Division
2. Interface and implementation
The principle here is to separate what
something does from how it does it
• Interface – e.g. the buttons on front of your
CD recorder – similar to a legal contract
• Implementation – e.g. the mechanism inside
your CD recorder

4. Extensibility Mechanisms
1. Constraints – These extend the semantics of
element by allowing us to add new rules
2. Stereotypes – allows us to add a new
modelling element based on existing one – we
define the semantics of the stereotype
ourselves; Stereotype add new element to the
UML metamodel
3. Tagged value – allows us to add new ad hoc
information to element’s specification

1. Constraints – simply a text in in braces { }
that specifies rules that must be maintained as
true.
2. Stereotype – represent a variation on existing
element but with a different intent. Each
element can have at most one stereotype,
define a set of tagged values and constraints,
associate a new icon. You have to define
semantics of the new element somewhere i.e.
put a note on the model or refer to doc. Use
ST name in << >>or the icon. You can ST
relationships as well as classes

3. Tagged Values – allow you to add your own
properties to model elements.
{tag1=value1, tag2=value2, …, tagN=valueN}
i.e. {auther=Vinil Gupta}

Architecture
The organisational structure of a system,
including its decomposition into parts, their
connectivity, interaction, mechanism and
the guiding principles that inform the
design of a system OR
The highest-level concept of a system in its
envionment

Architecture
UML captures the strategic aspects of a
system in a “4+1 view” of architecture
Logical view
Process view
Implementation view
Deployment view
Use Case view

Architecture

Architecture
1. Logical View - captures the vocabulary
of problem domain as a set of classes
and objects. The emphasis is on
showing how the object and classes that
compose the system, implement the
required system behaviour.

Architecture
2. Process View – models the executable
threads and processes in our system as
active classes. It is really a process in our
system as active classes. It is really a
process-oriented variation on the logical
view, and contains all the same artfeacts.

Architecture
3. Implementation view - models the files
and components that make up the physical
code base of the system. It is also about
illustrating dependencies between
components, and about configuration
management of set of components to
define a version of the system.

Architecture
4. Deployment View - models the physical
deployment of components onto a set of
physical, computational nodes such as
computers and peripherals. It allows you
to model the distribution of components
across the nodes of a distributed system.

Architecture
5. Use Case View – all of the other views
derived from the use case view. This view
captures the basic requirements for the
system as a set of use cases and provides
the basis for the construction of other
views.

Architecture
Under UP the 4+1 architecture is not
created in one go, rather it evolves over
time, using stepwise refinements. Each
iteration captures just enough information
about the system to allow it to be built.

UML

More Related Content

What's hot (20)

Similar to UML (20)

UML

Editor's Notes