What's New in UML 2.

0
M.W.Richardson Lead Applications Engineer I-Logix UK mrichardson@ilogix.com

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

What is UML?
Unified Modeling Language Comprehensive full life-cycle 3rd Generation modeling language
Standardized in 1997 by the OMG Created by a consortium of 12 companies from various domains I-Logix a key contributor to behavioral modeling

Incorporates state of the art Software and Systems A&D concepts Matches the growing complexity of real-time systems
Large scale systems, Networking, Web enabling, Data management

Extensible and configurable Unprecedented inter-disciplinary market penetration UML 2.0 is latest version in the process of being released

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Advent of the UML

UML 0.9 & 0.91 Released UML 0.6 - Dr David Harel adds Statecharts OMG Issues RFP Ivar Jacobson (Objectory) join them and add OOSE Grady Booch and Jim Rumbaugh begin unifying Booch & OMT Methods begin to merge UML 2.0 RFP Response for UML 1.0 UML 1.1

UML 1.3

UML 1.4

No Of Identifiable OO Modelling Languages Increases from <10 to >50 Identifiable OO modelling languages began to appear Method Wars Begin!

Mid 70s Late 80s

1989

1994

1995

1996

1997

1999

2001

2004

2004+

OOSE = Object Oriented Software Engineering Method OMT = Object Modelling Technique
I-Logix 2004 Tampere OO day 14/12/2004
www.ilogix.com

UML 2.0 Submissions

Infrastructure
Simplify and rework the hairy underbelly of the UML Align with MOF

Superstructure
Contains most user-visible features Improve scalability and architectural support Improve ability to model business workflows Add semantics of state machine inheritance

OCL
Object Constraint Language is used in the definition of the UML itself General improvements of the OCL

Diagram Interchange
Add ability to interchange diagram to the existing XMI

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

UML 2.0 Diagrams

Structure Diagrams Object Diagrams Structural Diagrams Deployment Diagrams Component Diagrams Communication Diagrams Interaction Diagrams Package Diagrams Class Diagrams Activity Diagrams State Machine Diagrams Behavioral Diagrams Interaction Diagrams Use Case Diagrams Timing Diagrams Sequence Diagrams

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Ports & Structured Classes

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

How can we model the following in UML?

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

PC System with UML 1.5

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Improved Design with UML 1.5

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Internal View of PC

Problem: Not obvious that the instance of Motherboard created by the PC is connected to the instances of USBCard and GraphicsCard created by the PC.

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

PC System

Problem: No way to cleanly specify which instance of pc is connected to which instance of Keyboard

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

UML 2.0 Ports

Ports are named connection points Ports allow a part to provide an interface across the boundary of its enclosing structured class without revealing to the client of the service the internal structure of the structured class
Client talks to the port without internal knowledge

Ports are typed by their interfaces

Provided interfaces Required interfaces

These interfaces can consist of synchronous and / or asynchronous operations

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

UML 2.0 Ports

Port

Provided Contract

Required Contract

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Devices

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

PC System : Plug & Play

Part Structured Class

Connector

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

PC Internals
Relay Port

Note here that the PC actually does nothing, all the external ports are connected to internal parts.

Behavioral Port

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Things to Remember about Ports

Ports are optional!
There is NOTHING you can do with ports that you cant do without them

Ports enforce encapsulation of internal parts

Parts can publish services across the boundary of their owning composite classes without revealing the to the client of the service which part offers it Parts are typed by interfaces
Compatible ports are conjugates one offers, the other requires the same or

compatible interface Sub-classed provided interfaces are compatible with super-class required interfaces

Ports are a design pattern

All design patterns have pros and cons
Con: Ports are instantiable and so take up some amount of memory and require

some amount of execution time

Ports are implemented by classes that provide behavioral delegation services to their clients

Ports can have multiplicity and can be connected dynamically

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Ports Example

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Easy testing

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

White Box View

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Sequence Diagrams

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Horizontal Decomposition
Messaging between structured classes

Interaction Occurrence

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Vertical Decomposition
Messaging between structured classes
Part Decomposition

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Interaction Fragment Operators

sd named sequence diagram Naming ref reference to interaction fragment loop repeat interaction fragment opt optional exemplar Flow of Control alt selection par concurrent (parallel) regions seq partial ordering (default) (aka weak) strict strict ordering Ordering criticalRegion identifies atomic fragments assert required (i.e. causal) neg cant happen or a negative specification Ignore/consider messages outside/inside causal stream

Causality

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Interaction Operator : Loop

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Interaction Operator : Opt

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Interaction Operators : Critical Region

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Inherited State Behaviour

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Inherited State Behavior

Assumes Liskov substitution principle for generalization:

A subclass must be freely substitutable for the super-class in any operation

You can Add new states Elaborate sub-states in inherited states Add new transitions and actions You cannot Delete inherited transitions or states

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Example: Generalization
Modified action list New sub-states and transitions New and-states

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Activity Diagrams

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Activity Diagrams
graspAt
interruptable section interrupting edge

Emergency Stop

Proximity Alert
Position

Interrupting edge Event reception or exception

Compute joint angles (a,b)

event reception

Input pin

Joint 1 to a

Joint 2 to b

Open manipulator

Rotate manipulator

Interruptible region
Joint_1
swim lane representing the objects executing the activities nested within

Joint_2

Joint_3

Grasp Object

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Timing Diagrams

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

Timing Diagram
send(value)

Transceiver
Idle Receiving Sending

Coil Driver
Receiving::High Receving::Low Sending::High Sending::Low Tristate

transmit(value)

evDone

{1 ms +/- 0.2ms}

tm(bitTime) send(value)

{3 ms +/- 0.2ms}

Monitor
Initializing Acquiring Reporting Idle

Time

A Timing Diagram shows the timing between objects.

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com

UML 2.0 Summary

Makes it easier to construct scaleable architectures Makes exchange of models between tools possible Facilitates use of UML by Systems Engineers

I-Logix 2004 Tampere OO day 14/12/2004

www.ilogix.com