| Chapter 3. Creating the UML Model | ||
|---|---|---|
 |  |
|
| Chapter 3. Creating the UML Model | ||
|---|---|---|
| | |
|
Contents
This section describes how to create the UML model that is used as input to a Jamda-based model compiler - the input model. To be able to make the best use of all the features of Jamda, the input model must follow some simple conventions, and use a basic UML profile - a set of known stereotypes and tagged values. This section describes what should be included in the input model - and what should be missed out. An example of a Jamda-style model can be found in the Ecomm2J sample e-commerce system in the installation.
This section also assumes a reasonable knowledge of UML modelling. For more information, start with the Object Management Group UML Resource Page or Embarcadero UML Central.
The core Jamda classes in the com.ashridgetech.jamda.uml package assume that the input model uses a basic UML profile, which is described below. These elements must be included in the UML input model and used on the appropriate elements if all the features of Jamda are to be available.
You should create these stereotypes in your input model and use them as described below.
The input model should use the following tagged values, which belong to the property stereotype:
Basic Jamda UML Tags
Attribute with the Property stereotype
Zero or more UML Actors who can read the value of this property
Shows which of the Actors in the UML model can read the value of this property outside the system. If the tagged value is not present, all Actors can read the value. If the tagged value is present, but without any Actors, no Actors can read the value. This tagged value is used by the Property.getReaders() method.
Attribute with the Property stereotype
Zero or more UML Actors who can update the value of this property
Shows which of the Actors in the UML model can update the value of this property from outside the system. If the tagged value is not present, all Actors can update the value. If the tagged value is present, but without any Actors, no Actors can update the value. This tagged value is used by the Property.getWriters() method.
The logical "business" entities of the domain should be represented by classes that use attributes and relationships as defined below. These classes may be assigned a stereotype that will be recognised by the Jamda ModelTransformers that you define and configure in your model compiler.
The logical entity classes described above must have an attribute with public visibility and the Property stereotype for each property of the class. Jamda recognises these attributes and exposes them in the list of Propertys for the class.
Relationships between classes must be included in the model as UML associations. Jamda includes association ends at the opposite ends of the associations of a class in the Propertys for that class. The properties of the association ends must be set carefully to show the requirements of the relationship. The association end properties which may be set are:
Jamda uses the name of an association end (a role name) as a Property in the class at the other end of the association. If the name is not present, the name of the class at that end of the association will be used instead. In many cases, this will be the best name, but when there are two associations between the same pair of classes, at least one of them will have to use role names for the association ends.
Jamda will create a Property in the class at the other end of the association only if this is set to true.
The Property in the class at the other end of the association is read-only unless this is set to true.
Jamda exposes this in the Property in the class at the other end of the association so that model compilers can make decisions about how to deal with the association. The recommended approach to using the three possible values with Jamda is:
Use this value for associations where neither class is "part of" the other, and each is accessible in its own right. Set the aggregation property to none at both ends. An example in the Ecomm2J sample system is the association between Customer and Salesperson.
Use this value for associations where objects of one class "belong to" another, but are still accessible in their own right. Set the aggregation property to composite at the owning end. An example in the Ecomm2J sample system is the association between Customer (owner) and CustomerOrder.
Use this value for associations where one class is "part of" another, and not accessible except via the containing object. Set the aggregation property to aggregate at the containing end. An example in the Ecomm2J sample system is the association between Customer (container) and Address.
This section points out what features should not be included in UML model used as input to Jamda
The classes should not have get or set operations defined for the properties represented by public attributes.
The classes described above should not have operations defined to get, add, update or remove linked objects represented by relationships.
Although attributes and relationships are different features of a class, they have many similar characteristics, and it is often useful to be able to deal with them all in the same way. Jamda supports this with the concept of properties. A Jamda ClassType or InterfaceType makes available a collection of Property objects. The Property interface is an abstraction of the common characteristics of attributes and association ends, such as name, type and multiplicity. The collection of Propertys includes both the attributes with the Property stereotype, and the navigable association ends at the opposite end of the associations in which the class participates. It will also include Propertys represented by getter and/or setter operations. It is recommended that these are not used in the input model, but getter/setter Propertys may be useful when generating further elements from a generated ClassType or InterfaceType that has getters and setters instead of stereotyped attributes.
Jamda currently accepts models which conform to the UML 1.4 specification in the XMI 1.1 format. Jamda can be configured to apply an XSLT transformation to its input file in order to convert it to the exact form of XMI required. The distribution currently includes one converter, for the XMI produced by the MagicDraw UML modelling tool. This is MDtoNSUML.xsl in the xsl directory. See Create the configuration for more details on applying an XSLT transformation.
Jamda has been developed using models produced by the MagicDraw UML modelling tool. This is not free, but demo versions are available (limited to 20 classes), and the Standard Edition licences are not too expensive compared to many other UML tools. Download a demo version from www.magicdraw.com.
Work is in progress to extend Jamda to accept UML models produced by other tools, including some that are free.
These tips apply to MagicDraw 5.5 onwards
| |  | |
| Chapter 2. Getting Started |  | Chapter 4. How to build a Model Compiler with Jamda |