new for uml 2
TRANSCRIPT
-
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
-
8/9/2019 New for Uml 2
2/13
Jim Schardt 2008 Educational Experiences. Page 2 of 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).
-
8/9/2019 New for Uml 2
3/13
Jim Schardt 2008 Educational Experiences. Page 3 of 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.
-
8/9/2019 New for Uml 2
4/13
-
8/9/2019 New for Uml 2
5/13
Jim Schardt 2008 Educational Experiences. Page 5 of 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
-
8/9/2019 New for Uml 2
6/13
Jim Schardt 2008 Educational Experiences. Page 6 of 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.
-
8/9/2019 New for Uml 2
7/13
Jim Schardt 2008 Educational Experiences. Page 7 of 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/9/2019 New for Uml 2
8/13
Jim Schardt 2008 Educational Experiences. Page 8 of 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.
-
8/9/2019 New for Uml 2
9/13
Jim Schardt 2008 Educational Experiences. Page 9 of 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.
-
8/9/2019 New for Uml 2
10/13
Jim Schardt 2008 Educational Experiences. Page 10 of 13
Figure 11: Interaction Overview Example** (pg. 407)
-
8/9/2019 New for Uml 2
11/13
-
8/9/2019 New for Uml 2
12/13
Jim Schardt 2008 Educational Experiences. Page 12 of 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)
-
8/9/2019 New for Uml 2
13/13
Jim Schardt 2008 Educational Experiences. Page 13 of 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)