Introduction

ArgoUML is by default initialised with a Java model. This model contains too much stereotypes and data types when designing UML diagrams for ArchGenXML. Furthermore, many of the stereotypes, data types and tagged values which are valid for ArchGenXML, are not available in the default model. For this reason a custom ArgoUML model has been created specifically only to facilitate the allowed stereotypes, data types and tagged values that are comprehended by ArchGenXML.

Next will be illustrated descriptions of parts of this model, where the model can be found and how to use it.

Model

Currently the ArchGenXML specific model provides the following.

Stereotypes

ArchGenXML stereotypes are available for:

• Model
• Package
  
• Interface
• Class
• Operation

Below are some screenshots illustrating the use of ArchGenXML stereotypes.

Data types

ArchGenXML core data types are available, on purpose no aliases are available. All available data types will therefore be mapped to unique widget types and preventing the confusion that different data types might map to the same widget type. Only one minor exception as been made, instead of ''integer'' the name ''int'' is used because ArgoUML requires this data type to be present as a default for newly created attributes.

Below is a screenshot illustrating the use of ArchGenXML data type for an attribute.

Tagged values

Many different sets of tagged values for Model, Package, Class, etc. are interpreted by ArchGenXML. Unlike stereotypes it is not possible to implementhese this in an elegant way that only the tagged values allowed for Model are avaialbe for Model, idem. for Package, etc. Henceone long list of tagged values is available for Model, Package, etc.

Below is a screenshot illustrating the use of ArchGenXML data type for an attribute.

Associations

Defining association in ArgoUML is easy when following these guidelines.

Aggregation

Use an aggregation when instances of class Bar should be referring to instances of class Foo. Note that this does not mean that instances of class Foo are contained in instances of class Bar. Deleting of instances on either side of this association does not affect the existence of instances on the other side of the association.

An aggregation like this is created by drawing a default association line from the right side of class Bar to class Foo. Name both association ends, the one at class Bar, call it Bar and the one at class Foo, call it Foo. Note that on either side of this association multiplicity can be altered from the default '1' (not shown in the class diagram) to e.g. '0..*' (which will be shown in the class diagram). When an association end has a multiplicity that can be greater then one, please name that end of the association Bars or Foos, whatever is relevant. In the generated code, this will result in the following field attribute.

relationship='foo_bars'

This relationship will be used in the ReferenceField and BackReferenceField in the generated code.

When the association has been created from class Bar to class Foo, one can navigate from instances of class Bar to instances of class Foo and one can manage the aggregation on the association end of instances of class Bar. Because Plone stores its instances in an object oriented database, it offers with ease the possibility to navigate and manage backwards. By adding the following line to the 'CLASSES' section in the ArchGenXML config file, these back references will be supported.

backreferences-support: yes

Note that for this the ATBackRef Plone product needs to be available and will be automatically installed with your product when named in AppConfig.py. Create this file in the root of your generated product and add the following line.

DEPENDENCIES = ['ATBackRef',]

The following description assumes you want to make an association from-class Bar and to-class Foo with multiplicity '0..*'. Start drawing an association on the right side of class Bar with the 'association line start' and stop on class Foo. There is no need to name the association, a name will be generated from the two association end names. Set the 'Multiplicity' at the to-class Foo to '0..*' or whatever is relevant.

In order to manage aggregations easily, install the product ATReferenceBrowserWidget (this is included from Plone 2.1.2 onwards). Add to the top-level package in your class diagram the tagged value 'imports' with the following value.

from Products.ATReferenceBrowserWidget.ATReferenceBrowserWidget import ReferenceBrowserWidget

Also add to that package the tagged value 'default:widget' with the following value.

Reference='ReferenceBrowserWidget'

Recursive Aggregation

This is almost similar to a normal association as described above, only this is a self reference. Use the 'self association line' to create one. It is usually used in parent(s)-child(s) aggregations. Please name the association ends accordingly.

Like with normal aggregations, changes on the back reference site are immediately available from the (forward) reference side.

Composition

This type of association enables instances of class Bar to contain instances of class Foo. This implies cascading delete on contained instances of class Foo when an instance of class Bar is deleted. Unlike aggregations (references), these compositions (containments) should be unique. E.g. a file cannot be contained in two completely different folders at the same time. To create a recursive aggregation, start drawing an association on the right side of class Bar with the 'association line start' and stop on class Foo. On the association end on the from class, i.e. class Bar, change the Aggregation type from 'none' to 'composite'.

There is no need to name the association ends or alter multiplicity because ArchGenXML, and Archtetypes for that matter, do not support this. Therefore '0..*' is always implied. The different class names of the to end of the composition will be named in the allowed_content_types of the from class. Backwards navigation is automatically provided by aq_parant, these is no need for a back reference like with aggregations.

Using existing classes

One of the advantages of object oriented software design and development is using existing classes instead of defining them over and over again. Suppose you would like to be able to add instances of class Document, Image or File to you custom class Foo.

Make the class diagram is is shows in the example below. Note that the attribute and operation Compartments for the classes on the left are hidden and that these classes have the stub stereotype. The latter means that they will not be generated. However, for class Foo, this means that it is possible to add instances of these classes to the (ordered) composition. In other words, Foo is an ordered container for Documents, Images and Files.

The following imports tagged values should be added to class Foo in order to indicate where to find the definitions of these already existing classes.

from OFS.Image import Image, File
from Products.CMFDefault.Document import Document

Download

This model is available from ArchGenXML svn trunk as argouml/argouml_profile.xmi and is included in ArchGenXML 1.5.0 onwards. Discussion on this topic can be found here http://plone.org/products/archgenxml/issues/30 .

Usage

This model can be used in ArgoUML by using the following command:

java -Dargo.defaultModel=location_of_archgenxml/argouml/argouml_profile.xmi -jar argouml/argouml.jar

Feedback

For the moment, use http://plone.org/products/archgenxml/issues/30 to communicate.