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.
and UML Distilled,
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
When defining a use case, other use cases can be (re)used,
either through the extends or through the uses
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.
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 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
An explicit characterization of the dynamic behavior of an individual object may be given by a state transition diagram.
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
In activity diagrams, parallel activity may be assigned to
activity falling under the responsibility of
a particular role, an actor or a part of the system.
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.
(C) Æliens 04/09/2009You 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.