Annex A: UML (Unified Modelling Language) Notation

Elements of the UML (Unified Modelling Language) notation are provided as this is necessary for the comprehension of the diagrams presented. The UML notation is a notation conceived for modeling object of applications and continue and extend, in particular, the notations of OMT (Object Modeling Technique) and Booch methods. More precisely, here we describe the principles of the use-case diagrams, classes, objects and sequence diagrams.

A1.Use-case diagram

Use-case allows us to model and structure the interactions between the users of a system, called actors, and the system itself. The use-cases represent a means of analysis of the users' needs and enable us to relate the actions made by a user with the reactions considering of a system. More precisely, a use-case is an abstraction of a set of concrete scenarios carried out by a type of users (Figure 1).

Figure 1: use-case

Use-cases can be structured and connected by two principal types of relations: relations of use (uses) and relations of extension (extends). A uses relation allows us to break up a use-case into use sub-cases. A relation of extension indicates a specialisation. In Figure 2, the interaction defined by the use-case A includes that of the use-case B, and the use-case C is a particular case of the use-case B.

Figure 2: types of relations between use-cases

For example (Figure 3), if one wishes to model the operations of credit transfers, they could identify two types of actors: distant customers and local customers. The two types of customers carry out a transfer, but the distant customers use a Minitel terminal, which generates a specific interaction (relation of extension). In all the cases, the operation of transfer includes a phase of identification (relation of use).

Figure 3: example of case of use (Muller, 1997, page 127)

Within the Object-Oriented Framework of CBR*Tools, we used the use-cases to express the interactions between a user and the system formed by the framework itself completed of its environment of handling. A use-case can then be connected to hotspots, which take part in the realisation of the use-case (Figure 4).

Figure 4: hotspots and use-cases

The use-cases also enable us to specify the type of the configuration of a hotspot in the realisation of an application made with CBR*cTools, while keeping the structure of the initial analysis (Figure 5). Three types of configuration are identified: specialisation (hotspot transparent box), instantiation (hotspot black box), or use of the behaviour by defect. If the same hotspot is used several times with various types of configuration, only one retains the most specific according to this command. One can then use the stereotypes of UML to indicate the type of the configuration on the relations between the hotspots and the use-cases.

Figure 5: use of hotspots

A2.Class diagram

A class of objects is represented by a rectangle, which consists of three parts (Figure 6):

name of the class,
attributes and
operations (or methods).

The lists of the attributes and the operations are however optional according to the degree of detail that we want to include in a diagram: these parts can be missed out empty or even to be totally absent. The attributes and the operations have a visibility (in particular public or protected), which is indicated by a symbol preceding their name: if the shape of a key is drawn, the access is called to be protected, because it is restricted to the current class and its subclasses.

Figure 6: attributes and operations of a class

Three types of classes are used:

concrete classes,
abstract classes and
interfaces.

Contrary to a concrete class, an abstract class, whose definition is in italic (Figure 7), cannot be instantiated. An interface is a class defining only operations and does not contain any code. An interface is identified by the indication of the stereotype Interface followed by its name.

Figure 7: abstract class and interface

An association represents a structural relation between various classes. An association is generally bidirectional, but we specify each time the direction of navigation. Association is then known as one-way (Figure 8) and also indicates the direction for reading the association. Each class plays a role in the association, which carries an indication of multiplicity (1 for one and only one object, and a star for zero to many objects). For example, Figure 8 indicates that an object of class C1 is associated with a set of objects of class C2, knowing that a same object of class C2 is associated with a single object of class C1.

Figure 8: one-way binary association

Various types of associations are also defined (Figure 9):

qualified associations,
derived associations,
associations with class and
aggregations.

A qualified association is an association which allows us to restrict the objects referred in an association thanks to a key. A derived association is an association made starting from another association. An association with class is an association itself managed by a class, which can thus provide attributes or operations specific for association. Lastly, a aggregation is a strongly asymmetrical association.

Figure 9: type of associations

Constraints can be posed on associations (Figure 10): constraint on the role of an association (for example, the objects are ordered), or between associations (for example, an association is a subset of another).

Figure 10: constraints and relations

Lastly, the classes can be connected by relation of simple or multiple inheritance (Figure 11).

Figure 11: relation of inheritance

A3.Object diagram

An object diagram allows us to concretely show a connection between objects. An object (or authority) is represented by a rectangle which generally comprises the name of the object and its class (Figure 12). However, the class or the name of the object can be omitted.

Figure 12: representations of an object

Figure 13 gives an example of a diagram of objects showing the relations of aggregation between a car, its wheels and its engine.

Figure 13: diagram of objects (P.A. Muller. Modeling object with UML. Eyrolles, 421 pages, 1997, page 136)

A4.Sequence/Interaction Diagram

A sequence diagram chronologically shows (from top to bottom) the interactions between a set of objects (Figure 14). Each object has a life line (vertical line). On these life lines, the periods of activity are indicated by fine rectangles which are superposed in the event of recursive call.

Figure 14: sequence diagram

Brigitte Trousse
Last modified: Fri Sep 28 13:50:50 MEST 2001