Unified Modeling Language

The Unified Modeling Language (UML) resulted from a joint effort of leading experts in object-oriented analysis and design, Grady Booch, Jim Rumbaugh and Ivar Jacobson, also known as the three amigos, all currently employees of Rational.

UML provides (graphical) notations to express functional, structural and behavioral properties of (object-oriented) systems. UML is not a method. It does not prescribe the steps to be taken in development. UML may best be regarded as a toolbox, from which the developer can choose a notation or technique as the need occurs.

Unified Modeling Language

UML

class diagrams -- conceptual structure
use cases -- functional requirements
interaction diagrams -- operational characteristics
package and deployment diagrams -- implementation
state and activity diagrams -- dynamic behavior

See www.rational.com/uml and UML Distilled, [Fowler97]

slide: UML

In this section we will look at a selection of the notational tools provided in the UML, as indicated in slide uml. For additional information see Rational's Web site. I also strongly recommend [Fowler97].

Class diagrams

Class diagrams represent (ideally) the conceptual structure of the system. Class diagrams typically consist of class descriptions and relations or associations between these. Class descriptions may be given as types, interfaces or actual classes, including attributes, methods and even visibility specifications. There is considerable liberty in how much detail is provided in either class descriptions or relations. As a rule of thumb, omit details as much as possible.

slide: Class diagrams

Special relations between classes are generalization or inheritance (indicated with the triangle in the diagram left in slide class-diagrams) and aggregation or containment (indicated with the diamond). In this example, just think of a compound as containing a number of instances of the type of which the compound is derived. The aggregation relation is often referred to as a has-a relation, which is, however, not appropriate when the object contained is actually used for delegation as discussed in chapter 2.

The diagrams on the right indicate how to depict arbitrary associations. Think for example of the relation between Employer and Employee classes. Clearly, in this case the role each class has with respect to the other class follows from the class name itself. In other cases it may be helpful to indicate the role explicitly.

When the association between classes is more complex, an explicit association class may be introduced, for example a class specifying a work contract, to describe the association in more detail.

Class diagrams may be refined further by adding annotations to the class descriptions and the relations. For example, relations may be more precisely defined by adding multiplicities (1,*,0..1,m..n, to indicate respectively one, many, optional or bounded). Class descriptions may be refined by adding notes, drawn as a box with a flattened edge, containing descriptive text.

The UML also allows for adding constraints, between curly brackets, and for the definition of so-called stereotypes, indicated by angular brackets as in <>, which represent generic constraints.

Use cases

Use cases define typical interactions between the user and the system. In other words, use cases define the boundaries between a system and its users. Use cases are critical in eliciting the functional requirements a system must satisfy.

slide: Use cases

A typical use case consists of an actor or role and a more or less detailed description of the actions that an actor performs to accomplish some task. A task may for example be the insertion of text, or the creation of a particular figure in a drawing editor. A distinction must be made between the overall goals of a user, like making a decent drawing, and the actions that must be performed to satisfy these goals. Only the latter can be the subject of use cases.

When defining a use case, other use cases can be (re)used, either through the extends or through the uses relation. The extends relation is similar to the inheritance relation for classes. The extending use case may override aspects of the extended use case. The uses relation is used to factor out common parts.

Interaction diagrams

Interaction diagrams are needed to clarify the actual behavior of a system, in particular the interaction between objects (or classes of objects) that result when executing a use case.

slide: Interaction diagrams

Interaction diagrams come in two forms, sequence diagrams and collaboration diagrams.

Sequence diagrams depict objects and their lifelines. When an object becomes active, the lifeline may be widened to a rectangle for the period of activity.

Collaboration diagrams depict the objects and their relations in a more static manner. Messages between objects, indicated by arrows, may be specified in greater or lesser detail. Also here, as a rule of thumb, details are given only when needed. To indicate message sequencing in collaboration diagrams numbering may be used, increasing or, as illustrated in slide uml-interact(b), branching.

Package and component diagrams

Although classes may be considered the building blocks of object-oriented applications and frameworks, they are usually not the units of deployment nor the units of reuse. See [Szyperski97]. Rather, packages and components may be considered as such.

slide: Package and deployment diagrams

A package diagram, depicted left, indicates the dependencies between packages, and possibly classes. Component or deployment diagrams depict the components, their exported interfaces and the dependency between components.

Although package and component diagrams are usually implementation-level diagrams, it seems advisable to take clustering and component packaging into consideration in the early stages of design.

State and activity diagrams

The characterization of behavior given by interaction diagrams primarily concerns, as the name says, the interaction between objects. The dynamic behavior of the objects themselves and the global activity can only be inferred from such diagrams.

An explicit characterization of the dynamic behavior of an individual object may be given by a state transition diagram.

slide: State diagrams

A state transition diagram consists of states and transitions between states, indicated by arrows. The arrows may be indicated by expressions of the form


    event(arguments)[conditions]/action

indicating that a transition can take place when a particular event occurs and certain conditions are satisfied. The transition will then result in an action, which may possibly modify state/instance variables.

Individual states may contain the specification of actions in response to particular events and the entry and exit of the state. States may be grouped to form a single (super)state, such as state-0 in the diagram on the left in slide uml-state.

To characterize the overall activity of a system, or parts thereof, activity diagrams may be used. Activity diagrams consist of nodes indicating activities.

Since activity diagrams are rather unspecific with respect to the actual objects involved, such diagrams are most appropriate in analysing aspects of workflow. In contrast, state diagrams are usually tied to the implementation of objects, such as event-schedulers, with complex dynamic behavior.

Both state diagrams and activity diagrams allow for parallelism. In activity diagrams, parallel activity may be assigned to so-called swim-lanes, activity falling under the responsibility of a particular role, an actor or a part of the system.

Discussion

As said before, the UML provides a generic toolbox for analysis and design. It offers no method, so the question remains: when to use what? The answer to that question may be very simple. Just use what you need to convey the properties of the system in a clear and understandable way. The answer may also be very complex, since `clear and understandable' are somewhat elusive notions. Following [Fowler97], I would say: don't overdo. Use UML to clarify critical aspects of the system and highlights of design, and leave it at that. Never continue modeling when you experience it as a useless, or worse, boring activity.

The UML toolbox is very rich. It allows you to model every conceivable aspect of the system. Nevertheless, to my mind, graphical models are not always appropriate. But, on the other hand, most people like them and they often make a good impression, suggesting clarity ...

As concerns the use of UML, to some extent one can delineate a subset as core UML. Class diagrams lie at the heart of most object models. Dependending on the level of abstraction and the amount of detail, they may be regarded as either a domain model, concrete class design, or anything in between. Use cases delimit the functional requirements, and are essential for negotiating these requirements and also for phasing the delivery of the system. Most interesting, I think, is where combined modeling efforts lead to an indication of the validation and verification spots of the system. In particular, the combination of class diagrams, use cases and interaction (sequence) diagrams allows for spotting the high-risk parts of the system and, accordingly, for specifying test procedures to verify whether the system meets its requirement specifications.

[] readme course(s) preface I 1 2 II 3 4 III 5 6 7 IV 8 9 10 V 11 12 afterthought(s) appendix reference(s) example(s) resource(s) _

You may not copy or print any of this material without explicit permission of the author or the publisher. In case of other copyright issues, contact the author.