Creating the UML Model

Contents

What the model contains
Stereotypes
Actors
Core business object classes
Auxiliary business object classes
Dependent value classes
Attributes
Relationships
Rules and restrictions
Core business object inheritance
What the model does not contain
Property get and set operations
Relationship manipulation operations

This section describes how to create the UML model from which Gen2J generates the application - the input model. It describes what must be included in the input model, and what should be missed out. There are some important aspects of UML modelling which must be followed so that Gen2J can generate the application correctly. It refers to examples in the Ecomm2J sample e-commerce system installed with Gen2J.

This section assumes a reasonable knowledge of UML modelling. For more information, start with the Object Management Group UML Resource Page.

What the model contains

This section describes the elements which should be included in the UML input model.

Stereotypes

There are a number of named stereotypes which are used by Gen2J to identify the purpose of certain elements of the model. You must create these stereotypes in your input model and use them as described below.

UML Stereotypes used in the Gen2J input model

coreBusinessObject

Used with a UML class to show that it is a core business object.

readOnly

Used with a UML public attribute to show that the property generated from it can only be read, and not updated.

Actors

There should be one Actor in the UML model to represent each different type of user of the application. The Ecomm2J sample system has Actors such as Customer, Salesperson and Supervisor. Each Actor will have a different view of the system.

Core business object classes

There should be a UML class to represent each "business entity" or "domain object" involved in the application. A core business object "stands alone", and is not part of another object (although it may need to be related to other objects). It will nearly always have a unique identifying attribute, such as an Account Number, by which it can be looked up by a user of the system. Core business object classes may have subclasses, subject to certain restrictions. Examples from the Ecomm2J sample system are Customer , Salesperson, Order and Product.

Each of these classes must have the coreBusinessObject stereotype.

Auxiliary business object classes

There should be a UML class to represent each auxiliary business object. This is an object which does not "stand alone", and has to be "part of" another object (usually a core business object) to exist. It will be linked to the containing object by an association where the aggregation at the containing end is aggregate (see the “Relationships” section). If the containing object is removed, the auxiliary object will also be removed. An auxiliary business object does not have a unique identifier by which it can be looked up by a user of the system. Examples from the Ecomm2J sample system are Address and LineItem.

These classes do not have a stereotype.

Dependent value classes

There should be a UML class to represent each dependent value class. This is a class which is only used as an attribute of core business objects or auxiliary business objects. It does not participate in any relationships with other objects There is no example at present in the Ecomm2J sample system.

Attributes

The stereotyped classes described above must have an attribute with public visibility for each property of the class. In the generated application classes, Gen2J converts the public attributes of these classes into a private attribute and generates pair of get and set operations. If an attribute has the readOnly stereotype, only the get operation is generated.

Relationships

Relationships between the stereotyped classes must be included in the model as UML associations. Gen2J will create the necessary attributes in the generated classes, and also the operations to manipulate the linked objects. 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:

name

Gen2J uses the name of an association end (a role name) to name the attributes and manipulation operations 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.

navigable

Gen2J will create accessor attributes or operations in the class at the other end of the association only if this is set to true.

changeable

Not currently used by Gen2J

aggregation

Gen2J will generate different application features according to the nature of the relationship indicated by the three possible values of this property:

none

Use this value for associations where neither class is "part of" the other, and each is accessible in its own right. Both classes would normally be core business object classes. Set the aggregation property to none at both ends. An example in the Ecomm2J sample system is the association between Customer and Salesperson.

composite

Use this value for associations where one class is "part of" another, but still accessible in its own right. Both classes would normally be core business object classes. Set the aggregation property to composite at the containing end. An example in the Ecomm2J sample system is the association between Customer and Order.

aggregate

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 and Address. See also the “Auxiliary business object classes” section.

Rules and restrictions

This section describes certain restrictions which must be followed in order for Gen2J to process the input model correctly.

Core business object inheritance

A core business object class may inherit from another core business object class. However, only the leaf classes in the inheritance hierarchy (those with no subclasses) can be concrete classes. All core business object classes which have subclasses must be marked as abstract.

Warning

Core business object inheritance is not fully implemented in the current version

What the model does not contain

This section points out what features should not be included in UML model used as input to Gen2J

Property get and set operations

The stereotyped classes must not have get or set operations defined for the properties represented by public attributes.

Relationship manipulation operations

The stereotyped classes described above must not have operations defined to get, add, update or remove linked objects represented by relationships.