UML 2.0 Changes

UML 2.0 Changes
IT 792 – Model Driven Architecture
Weekly meeting: 01-Sept-2008

01-Sept-2008 IT-792 - MDA (UML 2.0 Changes)2
Disclaimer
• The UML 2.0 specification is huge and rich
• This presentation is NOT intended to be a detailed UML
2.0 specification… it’s only an early attempt
• This presentation will focus on the “end user” perspective
of changes in UML 2.0 – the meta-model changes may
be left out
• This presentation has been prepared for intra-team
session. Only for academic purpose. As part of course
“IT792 – MDA (research elective)” offered during Fall
2008 by Prof. Chandrashekar Ramanathan. International
Institute of Information Technology, Bangalore.

“Take away” from this presentation
• Inclusions
 UML 1.x concepts
• Code samples generated in UML 1.x
 UML 2.0
• Requirement for a new standard
• Existing, enhanced and new diagrams.
 Resources {books, web links, tools and other
references}
• A few presumptions
 UML 1.x concepts

http://lh6.ggpht.com/_rY4Kf26lJ4U/Rqg8JQLUvdI/AAAAAAAAACU/0uAVE0KE1Bw/Evolution.jpg
Model – outcome++
Acknowledgement++
OOAD – class modeling Grady Booch
OOSE – use cases, transition
diagrams, and interaction
Ivar Jacobson
OMT – notation for diagrams,
dynamic quality of software
James Rumbaugh
10 -15 years… OOAD+OOSE+OMT
= Standardized development
language
Grady Booch, Ivar Jacobson and James
Rumbaugh @ Rational Software
UML  1.x (1997)  2.0 (2004) 
2.1.2 (Latest specification)
Standardisation by OMG – Object
Management Group
++
References: Learning UML 2.0 (O’reilly) and www.omg.org

4+1 view model++
++ -
References: Learning UML 2.0 (O’reilly)[1]

Larger landscape of systems design+
+
• Where it has been introduced originally
 UML 1.x
• Diagram types
– Use case – interactions between system and user
– Activity – sequential and parallel activities within your system
– Class – classes, types, interfaces, relationships
– Object – instances of classes defined in class diagram
– Sequence – interactions between system where timing is
important
– Communication* – way in which objects interact, similar to
sequence {* renamed in UML 2.0, originally Collaboration}
– State machine – various states of an object, events, change
condition
– Deployment – how system is deployed in real
++ -
quoted from Learning UML 2.0 {Russ and Kim, O’Reilly}.
First edition – April 2006, Indian reprint – January 2007.

Larger landscape of systems design+
+
• What has been introduced originally
 UML 2.0
• Diagram types
– Timing – interactions between object where timing is important
– Composite structure – internals of a class or component, and
can describe class relationship
– Component* – important components within system and the
interfaces they used to interact with each other. {* UML 1.x, takes
a new meaning in UML 2.0, originally Collaboration}
– Package – hierarchical organization of groups of classes and
components
++ -
quoted from Learning UML 2.0 {Russ and Kim, O’Reilly}.
First edition – April 2006, Indian reprint – January 2007.

UML 1.x sample code++
• Sample code {programming language Java}
 Boundary
 Control
 Entity
++ - Chapter 13, Mastering Rational Rose, BPB publication
Order_Boundary
D:001 - Root_D
Mat_PersonalIIITBSemes
D:001 - Root_D
D:001 - Root_D
D:001 - Root_D
Mat_PersonalIIITBSemes D:001 - Root_D

New in UML 2.0
• Highlights of UML 2.0++
Increased degree of precision – more automation,
less ambiguity. Computer programs generating
models.
Increased modularity - eases understanding for new
users, and better for proficient.
Flexible hierarchies added by OMG – ease in
modeling complex system.
RCC (Rationalization + clarification + consolidation) -
remove redundant, enhance, and refine.
++
- Reference: “What’s New in UMLTM
2.0 ?” by Bran Selic
IBM Canada. April 2005.

Lets delve UML 2.0
• Modeling system workflow – Activity diagrams
• Modeling ordered interactions – Sequence
diagrams
• Focusing on Interaction Timing – Timing
diagrams
• Modeling class’s Internal structure – Composite
Structures
continued…

Lets delve in detail : UML 2.0
• Managing and Reusing Your System’s Part –
Component diagram
• Modeling an Object’s State – State Machine
diagrams
• OCL : Object Constraint Language
• Adapting UML: Profiles

Activity Diagrams

Activity diagram (4+1 Process View)
• Use case – what system should do.
• Activity diagram – how system should
accomplish the goal.
 Activity diagrams are good at modeling ‘Business
processes’

Activity diagram[1] – how it looks
Actions – important
steps in activity.
Edge types –
incoming / outgoing
Node – start / end
Diamond – decision /
merge

Activity diagram[1] - Activity and
action
Action – Lather, Rinse, Dry
Activity name – Wash Car
Don’t mistake ‘Activity’ with ‘Action’.
Action is a step in overall activity
Note: Activity frame can be omitted

Activity diagram[1] - Decisions
Guard conditions – if then else condition e.g.
[authorized] or [not authorized].
Only one edge is followed based on what condition
evaluates to TRUE.

Activity diagram[1] – Avoid multiple
guard condition evaluating TRUE
• Beware where multiple guard evaluate to TRUE
[item in stock] or [item out of
stock] and [rush order]

Activity diagram[1] – Merges –
better be clear as much as possible:
UML 2.0

Activity diagram[1] – multiple task at
same time
Fork Join
Computer assembly shows how “forks” and “joins” work
in a complete activity diagram

Activity diagram[1] – time events
Representing a recurring event e.g. Update Progress
Bar every 1 second.
Hour glass – represent Time Event, and text on top of it
represents wait time. e.g. Wait for 3 days before Send
Bill after Ship Order.

Activity diagram[1] – calling
activities or showing object
Pitchfork – To represent calling
other activity
Object node – Use object node to show an
activity flowing through an activity. Object
interactions, creation, modification or usage.

Activity diagram[1] – showing
Actions input and output
An Order object is input to Approve Payment action and
output from Receive Order Request
An input or output pin.

Activity diagram[1] – when an action
need only a part of object
Here, Approve payment action only need ‘Cost’ object as an
input from a ‘Order’ object.
Cost object is received using <<transformation>> to specify –
Only Cost from Order object.

Activity diagram[1] – showing how
object change state during an
activity
Object ‘Order’ change state during an activity. Object state
change from [pending] to [approved]

Activity diagram[1] – showing input
and output from an Activity
Above, Order object is input and output from Approve Payment
activity.
Note: When input and output are shown then initial and final
node are omitted.

Activity diagram[1] – sending and
receiving signals
Example:
• Sending Credit Card details to card provider.
• Collecting response from credit card provider. Based on response ie. approved or
denied order status may be shipped or delayed.
Receive Response as start node. In this case Initial node
may be omitted.

Activity diagram[1] – interrupting an
Activity
Interrupting event shown with a “Lightning bolt
arrow”.
Interruption region is shown by a dashed, rounded rectangle
around action which can be interrupted.
Diagram means – If Receive Cancellation is received while
Process Order is active, then interrupt activity and Cancel Order.

Activity diagram[1] – ending a flow
Flow Final Node, a flow final node terminates its
path only – not the whole activity
Note: Be careful when using flow final node after a fork. When a
flow final node is reached, then all process are terminated
including all processes running before node. If you like to run all
forked process to run to completion, make sure to add a join.

Activity diagram[1] – partition or
swimlanes

Activity diagram[1] – using
annotation

Managing complex Activity Diagrams
– connectors [1]
Connector – they come in pair
Note: If large number of different connectors are used, it can find
reader hard time pairing them.

Managing complex Activity Diagrams
– expansions [1]
Expansion region – large dashed rectangle with four aligned
boxes on either side.
Usage – expansion regions show that action is performed for
each item in an input collection. e.g. Each bug report is
discussed, if bug is [real bug] then activity proceeds,
otherwise bug is discarded and flow for that input ends.

Advanced Class Diagrams

Advanced Class Diagrams[1] – class
relationships

Advanced Class Diagrams[1] –
multiple inheritance
Note: Though UML supports multiple inheritance, however
in practice many don’t. e.g. Java, C#.
Reason: such as addEntry(…) is present in both parent
classes, so function call need resolution rules. And rules
change from language to language.

multiple inheritance
url – attribute not NULL
Rating – never less than 0
updateRating(…) – precondition {rating>=0}
Range specifier – “0 <= rating <= 5”

abstract class
Abstract class – does not implement all
methods
Notation:
Methods – written in italics
Class name – written in italics

abstract class
BlogStore inherits Store, implements
abstract methods “ store(…) and
retrieve(…)”

interface
Interface – does not implement any
methods.
C++ using abstract classes with no method
implementation.
Java / C# using special construct “interface”

Advanced Class Diagrams[1] -
interface
Stereotype notation
Ball notation

interface, abstract and concrete

Advanced Class Diagrams[1] -
template
• “I know the class will have to work with other
classes, however at this stage I don’t know
what those classes end up being”.
 If you find yourself in a similar situation use
TEMPLATES
 With an extra dashed border on
top right corner.
 ‘E’ is just a placeholder, can be
used later to tell type of objects
class will need to store.
Notation
<<bind>> <E->BlogEntry>

Sequence Diagrams

Sequence Diagrams[1]

Sequence Diagrams[1]
• Events – smallest part of an interaction. An
event is any point in interaction where
something occurs.
• Interaction - smallest part in sequence diagram
where ‘message/signal’ is sent by one
participant to another.

Sequence Diagrams[1] - message

Sequence Diagrams[1] – nested
message
When a message triggers more than one message at receiving side
before return statement to originating participant is made.
Definition

Sequence Diagrams[1] – message
arrow types
“A Return Message is Optional”

Sequence Diagrams[1] –
asynchronous message
1. foo() – asynchronous message, without waiting for
return you can continue sending other messages.
 Implementation – ????
Multithreading feature programming language

Sequence Diagrams[1] –
destroy
Participant2: ParticipantClass2, is <<created>>
and <<destroyed>> during course of sequence
diagrams

Sequence Diagrams[1] – from Use
Case to Sequence Diagram
UseCase to create a regular blog account. [taken from
Learning UML 2.0 {by Kim and Russels, Oreilly}]

Refining - Adding details and internals

More details –
 <<destroy>> - :AuthorDetails
 Asynchronous – clickSubmit()

Sequence Diagrams[1] – Sequence
fragments (new in UML 2.0)
Definitions and details next slide

Sequence Diagrams[1] – Sequence
fragments (new in UML 2.0)
• Why need sequence fragments
• Managing complex, huge sequence diagram
• Representing loops, alternate flows, interactions
with organized and structured sequence diagram.
• How to represent
• Box that encloses interaction
• Nested interaction – one or more box inside a box
• Important distinguisher
• Operator on top left corner. Operator denotes type
of sequence fragment.
• Types
• opt, ref, assert, loop, break, alt… [ For more
details/types refer UML 2.0 in a Nutshell, Oreilly ]

Sequence Diagrams[1] – using a
‘ref’ fragment

Communication Diagrams
(a.k.a Collaboration Diagrams in previous UML versions)

Communication Diagrams[1] –
Display interaction links
Definition – Diagram showing interactions between participant.
Also, known as Collaboration Diagram in previous versions.
Simpler to represent than Sequence Diagrams.
Ingredients – Participants, Links and Messages.
CD vis a vis SD – Designer’s personal choice. Sequence
diagrams is preferred. True SD is complex, however why
compromise when we get more details. [for more details refer table 8.1
Learning UML 2.0, By Kim and Russel, Orielly]

nested messages
Message invocation order:
1.messageA()  {1.1messageC()  1.2messageD()} 
2.messageB()

parallel messages
Message invocation order:
2a.messageB(), 2b.message() and
2c.messageC() all invoked at same time after
1.messageA()

Communication Diagrams[1] – same
message multiple times
Looping constraints
Looping constraint *[i=-0..9]
Guard condition [condition - true]

participant calling itself
When do we need it
 When an object calls its on method.
Talking to itself is acceptable in software world
otherwise it may sound absurd 

Communication Diagrams[1] – a
conversion from SD to CD
Our referenced SD: {built from Use Case “Create a Regular blog account”}
Click for TD

Identify participant involved

Establish link between all necessary participants, refer SD.

Other steps {disclaimer, each step can be performed separately} – Add
messages  Nested messages  Guard conditions  Return
messages {for all details keep referring SD},.

Timing Diagrams (new in UML
2.0)

Timing Diagram[1]
• Definition
• Interaction diagram type, which give detailed timing
information. However, Timing diagram are not just about
timing information.
• Why we need them
• When you can model what events to take place, however
you want to show when they will take place and how
recipient reacts.
• Applications
• Real time applications, or applications where you want to
model / follow strict timing pattern.
• Analogy
• Similar to logic analyzer for a PCB (printed circuit board).

Timing Diagram[1] – a simple
diagram
A mail server with logic analyzer; modeled using a timing
diagram.

Timing Diagram – exact time or
relative time measurements
Exact
measurement
Relative
measurement

Timing Diagram[1] – state diagram
States – { State1, State2, State3}
Participant – “p1”

Timing Diagram[1] – more details

Timing Diagram[1] - events
Event – is shown as an arrow from a state (State2) in
participant (p1:Participant) to a state (State1) in other
participant (p2:Participant2)

Timing Diagram[1] – timing
constraints
• What timing constraint gives us:-
• Tell how long given portion of interaction
should take place.
• Amount of time a participant remains in a
particular state.
• How long an event should take to be invoked
and received.

Timing Diagram[1] – timing
constraints

Timing Diagrams[1] – constraint
format specification
Timing Constraint
(representation)
Description
{t .. t+5s} Duration of event or state should be 5s
or less
{<5s} Less formal, however equivalent to
{t..t+5s}
{>5s, <10s} Duration of event or state should be
less than 5s, but less than 10s
{t} Duration of event should be ‘t’ secs. It
is a relative time, and value of ‘t’ can
be anything
{t..t*5} Duration of event or state should be t
multiplied by 5. This is relative timing. (
‘t’ can be any value of time)

Timing Diagrams[1] - constraint
format specification

Timing Diagrams[1] – arranging
participant on TD {a tip}
Easy to read, well organized
states
Untidy,
participant
misplaced

Timing Diagrams[1] – alternate
notation
• Timing diagrams represented below, will grow
big, unmanageable.
• With a increased participant count size of
diagram reaches a huge size so soon.

Timing Diagrams[1] – alternate
notation
• To reduce size of diagram, follow the alternate
notation.
The alternate Timing Diagram Notation
Good when many states to represent.

Timing Diagrams[1] – from SD to TD
• SD  Old “Create Blog account SD”.
• Click link to view  Referred Sequence Diagram
• Technique to generate TD from a given SD
 Place the participant correctly
• Rotate SD participant 90 degrees counter
clockwise {shown in next slide}
 Read sequence diagram to determine time of
events or states

Timing Diagrams[1] – rotating
participants “90º counterclockwise”

Timing Diagrams[1] – read SD,
depict state or event time on TD

Interaction Overview Diagrams

Interaction Overview Diagrams[1]
• Implements a bigger picture view
• IOD = {CD + SD + TD}
• IOD – define how different diagrams ie. CD, SD
and TD interact to solve
• A use case
– Or
• A particular system concern

Interaction Overview Diagrams

Interaction Overview Diagrams[1] –
parts of diagram
lifelines subtitles show combined list of
participant involved in interactions within
overview

creating IOD for a blog account
Legends
Create a New Regular Blog
Account
iod = interaction
overview diagram
sd = sequence diagram
cd = communication
diagram
td = timing diagram

sd =
expanded,
detailed

sd, cd and td
= all expanded,
detailed

Before we
Lets determine where we started from,
where we reached and what’s next

We started with
• Rev up of UML1.x code samples generated
using Rational Rose tool.
• UML (Unified Modeling Language) notations,
and where was each notation introduced i.e.
UML 1.x or UML 2.0
• Who, how, why and what UML 2.0 has been
incepted.

We are introduced to
• Activity Diagrams
• Advanced Class Diagrams
• Sequence Diagrams
• Communication Diagrams (a.k.a. Collaboration
Diagrams)
• Timing Diagrams
• Interaction Overview Diagrams

What’s next
• Composite Structures – modeling class’s internal
• Component Diagrams – managing and reusing
system’s part
• Packages – organizing model
• State Machine Diagrams – modeling an object’s state
• Deployment Diagrams – modeling deployed system
• UML profiles – adapting UML
• Object Constraint Language (OCL) – defining
constraints
• UML 2.0s tools – applying UML 2.0
• And questions ????

What we have to learn to do,
we learn by doing.
Aristotle++
++
- http://www.quoteworld.org/quotes/570

UML 2.0 Changes – Part 2

What’s next
• Composite Structures – modeling class’s internal
• Component Diagrams – managing and reusing system’s part
• Packages – organizing model
• State Machine Diagrams – modeling an object’s state
• Deployment Diagrams – modeling deployed system
• UML profiles – adapting UML
• Object Constraint Language (OCL) – defining constraints
• UML 2.0s tools – applying UML 2.0 {≠ Covered}
• And questions ????

Questions from previous
session
Do an input pin and an output pin exist in pairs?
 Not necessarily. See figure 14-214, Page 540-41 from “The Unified
Modeling Language Reference Manual” (see references for more
details)
• Interplay and interchange between diagram?
 Could not find much on same. Will try to cover as part of weekly
discussion.
• State diagram and Timing diagram ?
 Will be partly resolved when state diagrams are discussed.
However, will also be covered as part of answer to Interplay
between diagrams.

Composite Structures (new in UML
2.0)

Composite Structures[1]
• Definition
• Diagrams apart from, primary UML diagrams
such as class and sequence diagrams, to
show how objects work inside classes, how
objects can achieve the goal.
• Why we need them
• To reduce gaps which are difficult to fill with
class and sequence diagrams. Examples
subsequent examples.
• Types
• Internal Structures, Ports and Collaborations.

Internal Structures[1]
• Definition
 Diagrams to show parts contained by a class
and the relationships between the parts.
• Example
Details in following slides

Internal Structures[1] - Example 
BlogEntry
Step 1 – BlogEntry is
composed of
Introduction and
MainBody
Step 2 – Improvement,
a MainEntry in
BlogEntry is
associated me with a
Introduction
Reason: Convenient for other
objects to ask an Introduction
object the MainBody object it
introduces.

BlogEntry
An unintended but a valid object structure.
An intended object structure.

BlogEntry
• Argument
 Class diagrams are not good at expressing how items
contained in a class relate. This is where Internal
Structures come handy.
• Counter argument
 An unintended structure shown previously can be
easily avoided while writing the code.
 Further, Sequence Diagrams can show object creation
and how they are connected.
• Then why to read
 Internal structures are convenient and simple way to
show relationship between contained items, especially
when contained items have a complex relationship.

Internal Structures[1] – Conversion Class
to Internal Structures

Internal Structures[1] – more details
A BlogEntry can contain
zero (min) or three (max)
pic:Image objects.
Connectors represent how
parts interact with each
other.
Alternate notation

Internal Structures[1] – representing
associations
Association - Dashed outline

Composite Structure - Ports[1]
• Definition
 A port is a point between a class and the outside
world. Distinct way of using a class, usually by
different types of clients.
• Example
• A Wiki class with UserServices and
Maintenance capabilities.
• Drawn as small rectangle on the
boundary of a class.

Composite Structures[1] - Ports
• Ports and interfaces
 Ports can be used group related interfaces to
show services available at that port.

Composite Diagrams[1] –
Collaboration Diagrams
• Definition
• Diagram showing objects by the role they play
in a scenario and providing high-level textual
description of what objects are doing.
[ showing object interaction performing a ]
• Any similarities
• Object diagram. But collaboration diagram
differ in focus.

Composite Structures[1] –
Collaboration and Sequence
Diagrams
Sequence Diagram -
”Implementing Chain Of
Responsibility design
pattern”
Collaboration
Diagram –
”Implementing Chain
Of Responsibility
design pattern”

An alternate notation
Participant  placeholder of objects.
Connectors  temporary links; mean that the runtime
objects communicate during collaboration, but the objects
don’t have to communicate outside the collaboration.

An real world example
 Object is not bound to a role; it can play different
roles in different collaborations.
 Objects in a collaboration are not owned by
collaboration; they may exist before and after
collaboration.
 Even though objects communicate in a
collaboration; they don’t necessarily communicate
outside the collaboration.

Component Diagrams

Component Diagrams[1]
• Definition
• Encapsulated, reusable and replaceable part of
software.
• Good candidates
• Perform key functionality, and used frequently in
software. Examples loggers, XML parsers, shopping
cart.
• Capacities
• Generalize, associate with other classes. Implement
interfaces, have operations.
• Class vis a vis Component
• A component can use classes and other
components to perform its task.

Component Diagrams[1] - parts
Basic Component Notation
An alternate Component Notation

Component Diagrams[1] - parts
Provided interfaces – provided services
Required interfaces – desired interfaces
OR Component Interfaces working together

Component Diagrams[1] – more
parts
Delegation connector
Assembly connector
Shows internal parts realize component
interfaces
Show components working together

Component diagrams – black box or
white box

Packages

Packages
• Definition
 Group of classes are modeled with packages. To
organize and avoid name collision among
classes.
• Examples
 Packages in Java, Namespaces in C#
• Notation
Credentials class is
located in security
package

Packages – dependencies and
visibilities
Dependencies
Users package imports only Credentials class
Visibility
“+” – public visibility
“-” – private visibility

Packages – managing packages
Changes in one can effect other. Tip
avoid cycles.

Packages – managing packages
Solution – reduce to one package or factor out a new
package

State machine diagrams

State Machine Diagrams[1]
• Definition
 To show how state of an object or system is
important factor in its behavior.
 Add on to activity and other interaction diagrams.
• Applications
 Real time system / mission critical systems such
as Heart Monitoring System
 Dedicated devices whose behavior is defined in
terms of state such as ATM.
 Gaming application/s.
 Network communication protocols.

State Machine Diagrams[1] -
essentials
Example : State Machine Diagram for a CD player.

State Machine Diagrams – internal
behavior and transitions
Internal behavior – behavior when object
is in this state.
Internal transitions – transitions that cause reaction
within same state, but doesn’t cause object to
change state.

Deployment diagrams

Deployment Diagrams[1]
• Definition
 Diagrams showing physical view of the system.
• Usage
 Show how software gets assigned to hardware
and how pieces communicate.

Deployment Diagrams[1] – web
application

Deployment Diagrams[1] -
constituents
• Nodes
 Hardware or software resource that can host
software or related files.
• Types
 Hardware – server, desktop PC, disk drives
 Software – Operating System, J2EE container,
web server, application server.

Deployment Diagrams[1] –
communication and specification
• Communication – how nodes communicate.
• Specification – an artifact specifying how
another artifact is deployed to a node.

Object Constraint Language (OCL)

Object Constraint Language[1]
• Need
 Defining constraints in a class diagram, or UML
diagrams in general.
• Alternate ways
 Programming language (C, Java) or natural language
• Issues
 Natural language ambiguous, Programming language
not understood by all
• Solution
 OMG proposed OCL
• Features – formal yet easy to understand language for
UML diagrams.

Object Constraint Language[1] -
types
• OCL has four built in types
 Boolean – true; false
 Integer - 1, 2, 4534523532, -200
 Real – 2.3423432, 11.700000
 String – “MDA”

Object Constraint Language[1]
-operators
Group Operators Supported
types
Examples
Arithmetic +,-,*, / Integer, Real “abc + def / ghi”
Additional arithmetic abs(), max(), min() Integer, Real marks.max(scorecard)
Comparison <, <=, >, >= Integer, Real abc > = 9
Equality =, <> All title <> ‘Idle’
Boolean and, or, xor, not Boolean isStudent and (nation
= “India”)
String concat(), size(),
substring(), toInteger(),
toReal()
String title.substring(1,8)

example
• Pulling it together

Object Constraint Language[1] –
constraint types
 Invariant
• Must always be true, otherwise system in invalid state.
Example : roll_numer always greater than zero.
 Pre conditions
• Defined on a method, checked before method executes.
 Post conditions
• Defined on a method, checks values after method
executes.

Object Constraint Language[1] –
example
Sample constraint
context BlogEntry :: incrementRating (amount : int) : void
pre: amount < = 100
post: rating = rating@pre + amount

automation
• OCL constraint from UML model to perform
constraint checking
• Enhance integration, from UML to runtime
model.
• Checking errors early, reduce debugging time.
• Tool support
 ArgoUML, ocl4java, and Dresden OCL Toolkit
• OCL tool support will become more mature with
advancement in MDA and Executable UML.

UML Profiles

UML Profiles[1]
• Definition
 Way to adapt UML to a particular platform
J2EE, .NET or domain such aerospace, telecom,
or healthcare.
• Constituent
 Made up of stereotypes, tagged values and
constraints
• Earlier UML versions
 UML1.x allowed stereotypes on fly. Cause of
confusion to modelers.
 UML 2.0 fixed by declaring these stereotypes
and tagged values.

UML Profiles [1] – stereotypes and
tagged values
• Stereotypes – signify element has special use
or intent.
 Define name of stereotype surrounded by angle
bracket or guillemots.
 No limit on number of stereotype applied to an
element.

UML Profiles[1] – tagged values
• Definition – provide extra information to a
defined stereotype.
 Can apply multiple stereotype to an element,
each with its on tagged value.

UML Profiles[1] – constraints
• Definition
 Constraints impose rules and restrictions on
model elements.
 Example in subsequent slide.

UML Profiles[1] – creating a UML
profile
• When
 When standard OMG or toolspecific profile is
unable to express your model.
• How
 Extend UML meta-model or meta-class object to
define new stereotype.
 Enhance stereotype with tagged values.
 Define constraints to apply additional rules and
constraints.

UML Profiles[1] – creating a UML
profile

UML Profiles[1] – why bother
• Real power comes when defining a new, or a
common vocabulary between domains.
• Leverage tools to generate automatic code.
• Examples:
 Omondo Eclipse Plugin provides J2EE profile
 OMG maintains some common profiles such as
for CORBA and testing. Testing profile provides
mapping to JUnit { commonly used Java unit
testing framework}

Wrap up
 UML 1.x and UML 2.0 from beginners to intermediate
levels.
 How to model a system with a simple WikiBlog
examples.
 Old, or enhanced features in UML 2.0
 New diagrams or notations in UML 2.0
 Introduction to Object Constraint Language
 Introduction to UML profiles

UML – Resource links (Tools and
books)
• OMG resources link
 Tools and tutorials
• http://www.uml.org/#Links-General
– The current UML specification for free download
– Standard UML Profiles and related specifications
– Articles about UML
– UML Resource Pages
– UML Tutorials
– And more
• Others
 Tools
• http://en.wikipedia.org/wiki/List_of_UML_tools
– List of UML tools maintained on Wikipedia.org
 Forum
• http://www.uml-forum.com/
– UML forum is a web community on Unified Modeling Language (UML)

References, recommendation and
copyrights information

References
[1] – Learning UML 2.0; by Kim Hamilton, Russell
Miles; Oreilly Publication
Recommended reading
The Unified Modelling Language Reference
Manual, Second Edition, by James Rumbaugh,
Ivar Jacobson, Grady Booch; Pearson
Education (LPE)
UML 2.0 in a Nutshell [Oreilly]
Mastering Rational Rose [BPB]
UML Toolkit [John Wiley and Sons]

References
• Web resources
 http://www.omg.org/
• For MDA, UML, OCL and XMI standards and other
specifications.
• Personal recommendation
 UML has extensive support in textbooks, toolkits and
on web.
 Most authentic and standard is OMG’s official website
{www.omg.org}.
 It is highly recommended that only standard
specification be followed.

Copyrights information
• OMG, UML, CORBA – Copyright © 1997-2008 Object
Management Group, Inc. All Rights Reserved.
• IBM – Copyright IBM Corporation 1994, 2008. All rights
reserved.
• JAVA, J2EE – Copyright © 1995-2008 Sun
Microsystems, Inc. 4150 Network Circle, Santa Clara,
California 95054, U.S.A. All rights reserved.
• C#, .Net – Copyright © Microsoft Corporation, Redmond
Washington. All rights reserved.
“All attempts have been made to acknowledge Copyrights and avoid infringement of terms,
trademarks of organizations. However, if in this material any information /
acknowledgement is found missing, please it be considered unintentional. ‘All Rights
Reserved’, trademarks, logos still to be considered property of respective organization
or standard.”

“A spider conducts operations that resemble those
of a weaver, and a bee puts to shame many an
architect in the construction of her cells. But
what distinguishes the worst architect from
the best of bees is this, that the architect
raises his structure in imagination before he
erects it in reality. ”
— (Capital, Vol. I, Chap. 7, Pt. 1)
Karl Heinrich Marx++
++ - http://en.wikipedia.org/wiki/Karl_marx

UML 2.0 Changes

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (18)

Similar to UML 2.0 Changes

Similar to UML 2.0 Changes (20)

More from manishthaper

More from manishthaper (8)

Recently uploaded

Recently uploaded (20)

UML 2.0 Changes