Using ArgoUML model with ArchGenXML data types, stereotypes and tagged values
Using ArchGenXML with ArgoUML is much simpler with this base model. It gives you only ArchGenXML data types, stereotypes and tagged values instead of the default Java stereotypes, data types and classes.
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.
