New for Uml 2

8/9/2019 New for Uml 2

1/13

Jim Schardt 2008 Educational Experiences. Page 1 of 13

Whats New for UML Version 2

Introducing UML 2

Version 2 of the Unified Modeling Language (UML2) provides many of the familiarUML1 diagrams, upgrades several diagrams making them more expressive, and adds anumber of new diagrams to keep up with the changes in object-oriented development.

The diagrams are organized into two main categories. Structural diagrams show the static

structure of a set of modeling elements. Behavioral diagrams allow you to focus on the

functional aspects of objects from different perspectives. Figure 1 provides acategorization of UML 2 diagrams.

Figure 1: UML Diagram Organization

Please note: Due to the newness of UML2, several example figures are copied from the

final UML2 Superstructure submission to the Object Management Group(www.omg.org). When you see a figure with a double asterisk after the caption (**), then

the figure was copied from the 3rd

revised submission to OMG RFP ad/00-09-02 for theUnified Modeling Language: Superstructure Version 2. The page reference at the end of

each figure caption with double asterisks is the page number in the UML2 Superstructuresubmission where the original figure may be found. The submission date is April 10,2003. Copyright 2001-2003 U2 Partners (www.u2-partners.org), including content

adapted from the OMG Unified Modeling Language Specification v. 1.4. Copyright

1997-2001 Object Management Group (www.omg.org).

Diagram

Structural Behavioral

Class Package State MachineActivity UseCase

Interaction

Sequence CommunicationProtocol State Machine

TimingInteractionOverview

BasicallyUnchanged

Many Changes

SignificantChanges

New

BasicallyUnchanged

Many Changes

SignificantChanges

New

CompositeStructure

Component Deployment

Object


2/13


The UML2 Superstructure submission was voted on and approved by the Analysis and

Design Task Force of the OMG in Paris on June 6th, 20003. As part of OMGs

standardization process, a Finalization Task Force (FTF) was created to produce the

formal, edited document and make minor changes to fix small problems in the approvedUML2 specification. Therefore, the examples shown here may need minor changes as a

result of the FTFs work. The OMG will publish the results of the FTFs effort at

www.omg.org.

Limitations Addressed in UML2

UML2 addresses many of the limitations of UML1 to include:

Support for component based development; Modeling of runtime architecture of the internal structure of composite classes; Provision for independent mini state machines known as submachines; Improved control and data flow in activity diagrams; More robust modeling of object interactions over time; Support for Model Driven Architecture (MDA) tools. Increased support for systems engineering not just software development.

UML2 Structure Diagrams

Class Diagram

The class diagram of UML2 has changed little from UML1. You will find all the familiarmodeling elements classes, attributes, operations, associations, multiplicity, roles,

qualifiers, and association classes.

Composite Structure Diagram

Often the things you are interested in modeling have an internal structure. UML1

provided a little notation for showing the internal structure of composites (the filled in

diamond shape indicating a strong form of aggregation). UML2 carefully defines thisnotion of composites in a composite structure diagram. Basically you use this diagram to

show the internals of a classes, components, and nodes using this diagram. Miniature

composite structure diagrams can appear on any other type of structure diagrams. Forinstance, a component diagram could show the internals of a component by providing a

composite structure diagram in that specific component. You can also use these diagrams

to express patterns of collaborating objects and the roles they play in a pattern.

Composite structure diagrams are composed of parts (classes with a defined role in thecontext of the enclosing composite), and connections (associations with limitations on

potential links in the context of the enclosing composite).


3/13


This diagram is most often used to show hidden internal details of a class, an object, or acomponent. Figure 2 shows a composite Car class with two parts. The rear part is a type

ofWheel class and the e part is a type ofEngine class. There are 2 rear parts and they

are connected via the axle connection to port p on the e part.

Figure 2: Internal Structure Diagram ** (pg. 144)

Component Diagram

When UML1 was first defined, component based design had not really gotten started.

UML2 had to address this issue and allow modelers and developers to explicitly show

components and how those components are wired together thus the componentdiagram. A component is defined as a replaceable unit with well defined interfaces that

separate operation specification from their method realization. Examples of components

include subsystems, enterprise java beans, OCXs, or a web service. Looking beyond

software, components could also be hardware really any replaceable unit with well

defined interfaces.

Components are shown as class boxes with interface symbols (lollipops and sockets). A

lollipop symbol represents an interface that is provided by the component and a socket

symbol represents and interface that is required by the component (must be provided bysome other component).

Figure 3 shows a store component with an OrderEntry provided interface and an

Account required interface. The diagram also shows the internal composite structure of

the Store with the Order, Customer, and Product unnamed parts. You can also see theball and socket connector where the Order component requires a Person interface and

the Customer component provides a Person interface. The small icon in the upper right

hand corner indicates that the class is stereotyped as a component. You can also just usecomponent as the stereotype instead of the little component icon.


4/13


5/13


Deployment Diagram

Deployment diagrams are still shown with connected 3D blocks as nodes. But, the word

Artifact replaces the old UML1 meaning of component. Artifacts are now what we call

the physical manifestation of software including executables, dll's, java jars, documents

and other files.The idea of showing execution nodes and communication paths remains unchanged. The

entire deployment notation you are used to using carries over to UML2. However, if you

want to show a software artifact you do not use components, you use class boxes with theartifact stereotype and/or a dog-eared icon in the upper right hand corner. You can

create deployment diagrams at the class and instance level.

Figure 5 shows a node at the instance level with two artifacts. The ShoppinCart.jardepends on the Order.jar.

Figure 5: Simple Deployment with Artifacts** (pg. 161)

UML Behavior Diagrams

Use Case Diagram

Use Case Diagrams have not really changed with UML2.

Activity Diagram

Activity Diagrams have changed to allow the modeler and the developer to express PetriNets. In UML2 most of the notation for activity diagrams is the same but activity

diagrams now have extra meaning. As Petri Nets these diagrams are more powerful atexpressing control flow, discrete object flow, and continuous object flow.

Figure 6 shows some of the basic notation for a complex Process Order activity. Anobject, Requested Order, flows into this activity and kicks off a sub activity Receive

Order. The small dot is the starting point for the Process Order activity and the bulls-eye is where the activity and all flows terminate. The diamond allows control to flow

based on a decision. The thick bar notation allows for forking the control flow in a


6/13


concurrent way. The diamond merges and the thick bar joins control flows as well. Anobject flow is also shown by the activity Send Invoices generating objects of the Invoice

class and which in turn flows on to the Make Payment activity. You can specify pre and

post conditions for an activity as well.

Figure 6: Example Activity Diagram** (pg.258)

UML2 retains the idea of swimlanes. When you want to model business processes useswimlanes. You can also use swimlanes to indicate who is responsible for a group of

behaviors described in an activity diagram. A swimlane is a way of partitioning activities

amoung classes. New to UML2 is the ability to have multiple dimensions. For exampleyou might have one dimension for business process job role and another dimension for

location of that job. See Figure 7 as an example.


7/13


Figure 7 Swimlane example** (pg. 277)

State Machine Diagram

The notation you already know for state diagrams carries over to the UML2 state

machine diagram. The ability of have submachines mini state machines that youcan reference from other state machines has been carefully defined in UML2.

You can place a frame around a state machine indicating its context. This is usually thename of the class that has the state machine for its internal dynamic behavior

specification.

The diagram in Figure 8 shows a state machine for an ATM. Notice the states are

surrounded by a frame with the name of the state machine. ReadAmount :

ReadAmountSM indicates a submachine is being used. The circle with an X in it and the

word aborted indicates an exit point from the submachine when there is an aborted

event that occurs while in the ReadAmount submachine, otherwise there is an automatic

transition from rheReadAmount

submachine to theVerifyTransaction

state.

Figure 8: ATM State Machine** (pg. 466)

Protocol State Machine Diagram

The Protocol State Machine diagram is new to UML 2. It is based on the state machinediagram but focuses on allowable sequences of behavior invocation on a class to express

a protocol instead of what happens inside a state. If you want to show the right invocation

order of operations on a class and expose the pre and post conditions for those operationsthen the Protocol State Machine Diagram is for you.

Figure 1Figure 9 illustrates a simple protocol state machine for a Door. Notice the frame

surrounding the diagram with the {protocol} property. The big difference in notation


8/13


between a state machine and a protocol state machine is in the transition line betweenstates. The transition is named as [precondition] event / [post condition]. These

transitions have no actions. Generally, the events are the names of operations on a single

class. When the Door is in the opened state, the Close operation may be invoked. Theprecondition that the doorWay has the property ofisEmpty must be true. The Close

transition has no post condition.

Figure 9: Protocol State Machine** (pg. 424)

Sequence DiagramSequence Diagrams are significantly enhanced. The basic notation for objects and tracelines looks the same. But, you now place a "frame" around the diagram. You can

reference or show mini sequence diagrams in a larger sequence diagram. And, you can

easily show alternative flows, optional flows, interaction, and a host of other flows in onediagram.

Place a sequence diagram inside a frame with the sd keyword. Instead of having object

instances you have connectable parts of classes. They are much the same as object

instances for the purpose of interactions. You can show more complex sequences byplacing frames inside the main sequence diagram frame. Some of the sequence

fragments you can use are:

ref: a reference frame to another sequence diagram alt: show alternative sequences based on some constraint (see Figure 10) loop: show iteration over a set of event sequences par: show event sequences that can happen in parallel critical: show a region of event sequences that must happen.


9/13


We are just getting started.

Figure 10: Sequence Diagram** (pg. 372)

Interaction Overview Diagram

The Interaction Overview Diagram is also brand new. This diagram is sort of like anactivity diagram but it focuses on events instead of actions. Use this diagram to show an

overview of interactions for a complex Use Case or a system.

Often use cases involve several objects interacting in a main flow, successful alternative

flows, as well as error flows. The complexity of allowable interactions increases with theuse of use case includes and extends. With UML1 you had to create many different

sequence diagrams, but it was easy to loose track of how these different diagrams related

to each other. The interaction overview diagram shows how major sequences are related

over time and control flow.


10/13


Figure 11: Interaction Overview Example** (pg. 407)


11/13


12/13


Figure 13: Timing Diagram** (pg. 411)

Miscellaneous Diagrams

Information Flow Diagram

One of the needs of Systems Engineers is addressed in a new Information Flowdiagram. This diagram shows the flow of information among entities. Figure 14 shows

the flow ofwage information from a Company to an Employee entity. Information like

wage is shown at a high level of abstraction without showing its structure. Otherdiagrams can be used to show how information gets represented.

Figure 14: Information Flow** (pg. 487)


13/13


Collaborations

The word collaboration is now associated with patterns of interaction between

collaborating objects in UML2. A collaboration is a composite structure diagram showing

the classes, their roles and constrains that define a pattern for reuse.

Figure 15 shows a collaboration, BrokeredSale, that consists of using two occurrencesof the Sale collaboration. The Sale collaboration involves two roles buyer and seller.

Classes are shown taking on the different roles of the Sale collaboration.

Figure 15: Brokered Sale Pattern** (pg. 135)

Documents

New for Uml 2