Major improvements in UML2
The major improvements in UML2 are:
- New concepts for describing the internal architectural structure of Classes, Components and
Collaborations by means of Part, Connector and Port.
- Introduction of inheritance of behaviour in state machines and encapsulation of sub machines
through use of entry and exit points.
- An improved encapsulation of components through complex ports with protocol state machines
that can “control “interaction with the environment.
- Improvements of the specification, realization and “wiring” aspects of the components.
- Integration of actions and activities and the use of flow semantics instead of state machines.
- Interactions are improved with better architectural and control concepts such as composition,
references, exceptions, loops and alternatives and an improved overview with Interaction
Overview Diagrams.
As compared with earlier versions, UML2 seems to have matured into a more complete language,
with improved integration of the various parts.
Architectural concepts in UML
Perhaps the most important improvement in UML2 with respect to modelling complex systems is the
increased architectural support. Therefore a class may describe its behaviour as a collaboration of
behaviour of instances of other classes contained in the class. The core concepts for describing this
internal structure are Part, Connector and Port. These concepts are described in the sub chapters
below.
Parts
The introduction of the Part concept in UML2 makes it possible to describe the internal structure of a
class. A Part is a property of the containing class meaning that the Part lives and dies as part of the
lifetime of an object of the containing class. Parts are set of instances of other classes.
The composition association in UML can also be used to describe composition as illustrated in
Figure 2.1. However, this model does not express completely what should be described. The
model describes a Car that consists of Axle, Wheel and an Engine. Each Axle is connected to at
least two and at most four Wheels (may be three Wheels). Each Axle is also connected to an
Engine. The Boat consists of an Engine and a Propeller. From this model it is possible that the same
instance of Engine is connected to an Axle in a Car and to Propeller in a boat at the same time.
Figure 2.1 Composition versus parts [18]
That is obviously not what the model should express. The model should describe the class Engine
independent of its use (encapsulation) and describe more precisely that an instance of class Engine
is part of class Car and is connected to an Axle of that Car. Another instance of Engine is part of
Boat and connected to a Propeller of that Boat. This is the main motivation for introducing the Part
and Connector concepts.
In Figure 2.2 the class Car has got an internal structure of instances of other classes (parts).
These internal parts and connectors will only exist as a part of an instance of the class Car. So
when a Car is created, e:Engine is connected to drive:Axle that has two or more instances of
w:Wheel. The car has also one or more sets of run:Axle where each instance has exactly one pair
of nw:Wheel connected. The figure also describes that the same instance of class Engine cannot be
part of both a car and a boat, which is possible according to the model shown in Figure 2.1.
Parts may have multiplicities in the format [n..m], where the n specifies how many instances are
created when an instances of the containing class is created. The upper level m specifies the
maximum instances that can be created.
Figure 2.2 Class with internal structure [18]
Ports
When instances shall be connected together, the connection point should be described formally. A
Port describes an interaction point for a class as described in Figure 2.3. Port is addressable,
which means that signals can be sent to it. A Port may have a provided interface that specifies
operations and signals offered by the class and a required interface that describes operations the
class expects from its environment. In the figure below has the port p has a required interface
named power and a provided interface named power train.
Figure 2.3 Ports connected to classes [18]
Use of ports enables specification of a class without knowing anything about the environment where
the class may be used. Classes can send and receive signals via ports, and a class can expose
operations through a port.
A port has an attribute isBehavior that specifies whether signal requests arriving at this port are
received by the state machine of the object, rather than by any parts that this object contains.
Such ports are referred to as behaviour ports. The state machine of the class will handle signals
that are sent to the behaviour port.
Connectors
A Connector specifies a link (an instance of an association) that enables communication between
two or more parts. In contrast to associations, which specify links between instances of the
associated classifiers, connectors specify links between parts only. A Connector may be attached to
a port or directly to a part as described in Figure 2.4. For example, an engine e:Engine in class
Car is connected by the axle connector to the instances in the set rear:Wheel.
Figure 2.4 Connectors and ports [18]
The figure also shows how connectors are used to connect instances of a class to instances of
different classes through ports. In the class Car rear:Wheelis connected to the port P of e:Engine
and in the class Boat the :Propeller is also connected to the port P of e:Engine. Although the part
e:Engine has the same instance name in the two classes Car and Boat they are different instances
where each of them belong to their containing class. Connectors and ports are excellent concepts
that enable more effective reuse of types and thereby encourage a component-based approach.
State machines in UML2
The major changes of the state machine concept in UML2 compared to UML1.4 are:
- Composite state with entry/exit points that increase the scalability and independence of
behaviour specification.
- State machine generalization that enables inheritance and specialization of behaviour.
- Protocol state machines that enable allowed sequences of signals and operation calls to be
specified.
- State machines that have operations that enable calls on state machines.
- State groups that enable common behaviour of events in different states.
A state machine is used to model discrete behaviour triggered by events. In addition to expressing
the behaviour of a part of the system, state machines can also be used to express the protocol
through a port. These two kinds of state machines are referred to as behavioural state machines
and protocol state machines. The state machine formalism used in UML2 is an object-oriented
variant of Harel state charts [39].
A state machine is triggered by different kind of triggers: signals, timeouts, operation calls and
change in values. A trigger causes a transition if the trigger is specified for the current state for that
state machine. A transition is described by actions that may cause new trigger events to be
generated.
The most important improvements of the state machine concept in UML2 are encapsulation of
behaviour in a composite state and inheritance of behaviour in sub types. These are described in
more detail in the following sub chapters.
Composite state
UML1.4 has no limitations on how to enter and exit composite states. It is legal to enter directly to
internal states of composite states and it is therefore difficult to specify composite states that can
be reused in other state machines. UML2 has introduced exit and entry points that control access to
a composite state. Figure 2.5 shows an example of a state machine with entry and exit points.
Exit and entry points are named points that are placed on the frame of the state machine.
Figure 2.5 Definition of Exit / Entry points [18]
Figure 2.6 shows an example on how the ATM state machine uses the state machine
ReadAmountSM. The transition rejectTransition ends in the entry point again of the state
ReadAmount. If we look at Figure 2.5 again, we can see that transitions through this entry point
ends in the state EnterAmount. The same semantic applies on transitions from states inside the
composite state. The transition triggered by the signal abort exits the composite state through the
exit point aborted and ends in the state ReleaseCard.
Figure 2.6 Use of Exit / Entry points [18]
Use of exit and entry points enables the design of components of behaviour that can be more easily
used in different places. This is analogous to use of procedures to obtain reusable operations.
An unnamed entry or exit point represents default behaviour. A composite state may have several
named entry and exit points.
Generalization of behaviour
The generalization and specialization concepts have been an important part of the UML language. It
has not been possible until now to inherit the behaviour of state machines. As shown in Figure 2.7
this has now been added to UML in the same way as ordinary inheritance of classes. New state
machine types can also be specified using inheritance independent of classes. New behaviour
specification can be added and parts of existing behaviour can be replaced as follows:
- States and transitions can be added
- States can be extended
- Transitions can be replaced or extended
- Targets of transitions can be replaced
- Submachine states can be replaced.
- Signals and operations may be added.
Figure 2.7 Specialization by extension [18]
Figure 2.8 shows how the composite state ReadAmount may be extended adding two new states
(SelectAmount, EnterAmount), three transitions (OtherAmount, ok rejectTransaction), and one
port. The figure also shows that it is allowed in UML2 to enter a composite state without going
through an entry point. The transition rejectTransaction in state VerifyTransaction ends directly in
the state EnterAmount.
Figure 2.8 Specialization of state machines [18]
UML profiles
UML defines three standard extension mechanisms: stereotypes, constraints and tagged values.
They are used to define extended meta classes in packages that are called UML profiles. Profiles
can be used to for instance, to tailor a UML metamodel to a specific platform such as EJB or .NET. It
can also be used to make new concepts to be used in models. An UML profile for animals will for
instance contain a meta class Cat as shown in Figure 2.9. The class Cat is tagged with the
keyword stereotype. Cat is an extension of the meta class Class and Cat can therefore only be
applied on instances of the meta class Class. The stereotype can extend an existing meta class or a
stereotype.
Figure 2.9 Defining UML extensions
A stereotype can have constraints. Constraints are expressed either by using OCL [40] or as
informal text. In the example above there are two constraints defined. The stereotype cat must
have the attribute isActive equal true and its interfaces can only contain signals. Stereotypes are
defined in a UML Package tagged with <<profile>>.
A stereotype is used to tag instances of the meta class as shown in Figure 2.10. Attributes can be
given values when the stereotype is applied.
Figure 210 Use of stereotypes
Summary
This chapter has presented the major features in UML2 as it is specified in the proposal from the U2
consortium. It has shown that UML2 has been improved with respect to modelling of behaviour and
composition. Behaviour can now be extended, which is important when more complex behaviour is
modelled. It is also possible to make fully encapsulated behaviour components, state machines,
which may enable reuse of behaviour. It seems that UML2 now has concepts that better support
modelling of systems that have to cope with conflicting initiatives and communication between
loosely coupled components.
UML also has an extension concept called profiles. Profiles are used to define metaclasses in UML to
tailor a UML model to a specific platform such as EJB.
Author: Geir Melby
From his Masters Thesis in Information and Communication Technology: Using J2EE Technologies
for Implementation of ActorFrame Based UML2 Models - Excerpt used with permission
References
1. Bræk, Rolf, Husa, Knut Eilif and Melby, Geir. ServiceFrame Whitepaper, draft 1.9.2001, Ericsson
NorARC, 2001.
2. Haugen, Øystein and Møller-Pedersen, Birger. JavaFrame: Framework for Java- enabled
modelling, ECSE2000, Ericsson NorARC, Stockholm, 2000.
3. Husa, Knut Eilif. Serviceframe Software Architecture Document, Initial Version 29/01/02, Ericsson
NorARC, 2002.
4. Sun Microsystems, Inc. Java Remote Method Invocation Specification, Available from:
http://java.sun.com/j2se/1.4/docs/guide/rmi/spec/rmiTOC.
5. Couloris, George, Dollimore, Jean and Kindberg, Tim. Distributed Systems: Concepts and Design
(3rd Edition), Addison- Wesley, 2001.
6. Winer, Dave. XML-RPC specification, Available from: http://www.xmlrpc.com/spec
7. W3C. Simple Object Access Protocol (SOAP) 1.1,2000, Available from:
http://www.w3.org/TR/SOAP/
8. Haugen, Øystein. JavaFrame 2.5 Modelling Guidelines, Ericsson NorARC, 2001.
9. Microsoft’s .Net web page. Available at: http://www.microsoft.com/net/defined/whatis.asp.
10. The Java™ Messaging Service web page, Documentation available from:
http://java.sun.com/products/jms/
11. The Java™ 2 Standard Edition, release 1.4 web pages, Documentation available from:
http://java.sun.com/j2se/1.4/.
12. The JavaBeans specification. Available from: http://java.sun.com/products/javabeans/docs/
15. EJB & JSP – Java On The Edge; Lou Marco; METT Books; ISBN: 0-7645-4802-06
16. Developing Java Enterprise Application; Stephen Asbury, Scott R. Weiner; Wiley; Second
edition; ISBN: 0- 471- 40593-0
20. SDL - Specification and Description Language, CCITT recommendation Z100;
21. MSC – Message Sequence Chart, CCITT recommendation Z120
22. T.Reenskaug, P. Wold, and O. A. Lehne; Working With Objects. Manning: Prentice Hall, 1995.
24. Rolv Bræk; Using roles with types and objects for service development. IFIP International
Conference on Intelligence in Networks, Smartnet 99, Bangkok, November
25. Haugen, Ø. and B. Møller-Pedersen. JavaFrame - Framework for Java-enabled modelling. in
ECSE2000. 2000. Stockholm.
26. Lars Boman; Ericssons Service Network: a “melting pot” for creating and delivering mobile
Internet services. Ericsson review 2/2000.
27. Robit Khare; Soap routing; the missing link; O’Railly Emerging Technologies Conference; UC
Irvine & Know How, Inc
28. Bræk, Rolv;On Methodology Using the ITU-T Language and UML; Teletektonikk 4.2000.
40. OCL – Object Constraint Language; Part of the UML standard.
43. OMG; IDL - Interface Definition Language
44. Sun Java Community; UML Profile for EJB;
48. Nilsen; Microsoft Corporation; Presentation SOAP routing and Message Path Modelling; PDC
2001, October 22- 26, 2001
