UML diagrams for JADE

[ConvertFromOldNGs]

by Geoff Davies >> Thu, 12 Nov 1998 4:18:34 GMT

Hi

Attached is a document which shows my attempts to use the UML standard to diagram the relationship between an order and its line items.

Not being a UML guru, I am not sure what kind of fist I've made of it.

Any feedback would be welcome.

Geoff Davies
JADE Education
gdavies@cardinal.co.nz

[ConvertFromOldNGs]

by Skull >> Wed, 25 Nov 1998 0:43:36 GMT

Geoff wrote:

"Attached is a document which shows my attempts to use the UML standard to diagram the relationship between an order and its line items."


Geoff,

Here is my 2.5 cents worth of comments, I have attached some word documents containing my suggested alternative UML class diagrams:

Your opening comment does not surprise me and actually says something about the tool in question. UML does not provide a superset of JADE concepts nor does it necessarily bridge the gap between OOA/OOD methodologies and language implementation. The high-level concepts in UML are adequate for OO modelling but there are gaps when it comes to linking certain design concepts with implementation constructs.
On representing JADE collections:

If you want a single consistent method for defining JADE collections in UML, then you probably want to consider defining collections as individual classes in some way. Firstly, it is often useful to define implementation classes such as collections in a separate class diagram. If you try to include them on the class diagram for the ‘model proper’ where they are used to implement multi-valued properties then it could add a lot of clutter since any given collection class is likely to be used many times. An option for representing collections in UML is to use parameterised classes (these look a lot like C++ template classes). A UML parameterised class can be use to parameterise the membership of collections providing a concise notation for representing JADE Sets and Arrays. However, this concept does not appear to extend to a representing a variable parameter list that would be required represent dictionary keys and their attributes generically. It may be necessary to use a UML extension such as a StereoType for this as you suggested.

On representing a JADE relationship:

JADE provides concepts that directly represent the endpoints of a bi-directional relationship (association, aggregation etc.). In JADE you define a property, which represents one end of the relationship you then define one or more of its inverse properties.
It is a pity that UML doesn’t have a way to directly tie the end-point of an association to its implementation. If this were possible, then in a tool such as Rational Rose you would simply define the JADE ‘properties’ as attributes and draw a line representing the association between the attributes. This notation could be used to clearly depict an association and its implementation in JADE.
As far as representing the properties that are the end-points of a relationship I believe these should be defined as attributes in the implementation or interface sections of the class in which they are used. Any multi-valued property (collection) should be of the actual collection type that will be defined in JADE.

The way I propose to map these to the endpoints of a UML association is to use the role concept and map roles to attributes by name. Refer to figure 1 in the attached for an example based on your own Order entry example.

Note: the role name is adjacent to the opposite class to the one that defines the attribute of the same name. This is required for correct UML role semantics and has the added benefit that the role name is also the JADE inverse property from the point of view of the class to which it is adjacent in the diagram.

This diagram together with a separate collection class diagram should be sufficient to define a JADE model unambiguously. You can, however, further annotate this model to provide some useful additional information using other UML concepts. For example, the UML semantics for the key/qualifier concept maps quite nicely to the keys of a JADE member key dictionary. Even if you have defined your dictionaries separately it may be useful to have this information replicated in the ‘main class diagram’ from the viewpoint of showing navigational aspects. In addition, you may wish to use UML constraints to directly represent JADE collection constraints such as ‘no duplicates’ or even ordered versus unordered.

Refer to figure 2 in the attached document for an example of an annotated association.
Note: in JADE, {ordered} implies an Array implementation, whereas {unordered} implies a set implementation. The UML constraint could also be used to depict the implementation explicitly using something like ‘Set of OrderLineItems’ or Array<OrderLineItem> if we used the parameterized class notation. The membership of a collection is actually a constraint, which may be more important when representing multiple inverse relationships.

If we chose to implement the orderLines property using an Array (ordered list), then the key qualifier for the role class: OrderLineItem could be an attribute such as lineNumber;

In these examples I left the associations are unnamed, you can give them a name but it won't currently be used in JADE. There is a subschemaHidden class in the JADE meta schema called Relationship, which was intended to allow the modelling of concepts such as Assocations and Aggregates. The name attribute in a JADE 'relationship' maps to the association name in UML. In the absence of an integrated design/modelling tool the Relationship class is of limited benefit and therefore remains unemployed for the time being at least.

[ConvertFromOldNGs]

by Robert Barr >> Wed, 17 Mar 1999 2:07:20 GMT

I've used the notation Skull describes and found it to be a clear and useful way of communicating design ideas between team members,
especially between technical and not-so-technical. I used annotations to describe aggregate relationship characteristics rather than a separate diagram for collections classes which was fine for our purposes, though
I concede it could get messy for an unambiguous blueprint.

A minor difference in our diagrams was that for aggregate relationships, I used the collection type as the reference name to save clutter in the class definition box as these tend to be rather verbose (eg AvailableFrieghtDestinationSet, ProductPremiumAttributeByPriceDict) - this improved readability which is important during design when you are using it for modelling rather than blueprinting for implementation. From a UML viewpoint, JADE collections are an implementation of object aggregation, so the collection class name is a chacteristic of the aggregate reference that lends itself to the role of reference
identifier as it helps with 'visualisation' of the implementation. I
have problems with spider diagrams covering office walls, so readability and visualisation while modeling were high on my list.

Rob