Welcome to the exff Pages

Abstract

This is The exff UML Usage Guide Release 0.1. This initial release is limited in scope as its only purpose is to generate discussion on the topic of developing data models using a UML diagram representation and EXPRESS as the text representation.

In order to make use of this user guide, the following knowledge and capability are required:

• ability to install a Java application, and perhaps the required JRE, on your computer;
• knowledge of data modeling;
• knowledge of the EXPRESS data specification language;
• knowledge of UML class diagram notation;
• ability to execute an XSLT transformation, and perhaps install an XSLT processor, on your computer.

Contents

Introduction
The Supported EXPRESS Subset
Developing the UML Diagram
Transform the UML into EXPRESS

Introduction

For Release 0.1 a free UML tool, Poseidon Community Edition. Poseidon CE was based on ArgoUML, which is an open-source project at SourceForge. Poseidon CE was chosen because it uses XMI as its underlying UML representation and because it was free. This allows the UML-to-EXPRESS mapping to be implemented as an XSLT stylesheet. PoseidonCE is also a Java application and therefore can run on many platforms (see Links and Resources ).

Users should study the guidelines for developing UML diagrams carefully. There are no diagnostic tools supplied with Release 0.l to assist should the transformation to EXPRESS fail.

The Supported EXPRESS Subset

A small but useful subset of the EXPRESS language may be created using Release 0.1. That subset includes the following constructs:

• single schemas that do not use or reference other schemas;
• real, integer, string and Boolean simple data types;
• entity data types;
• subtype declarations including multiple inheritance;
• ABSTRACT SUPERTYPE declarations;
• single-valued explicit attributes of the supported simple data types;
• single-valued explicit attributes referencing another entity data type;
• set-valued explicit attributes referencing another entity data type;
• optionality of explicit attributes.

The interface specification, select data types, inverse attributes, defined data types, general aggregation data types and constraints cannot be generated using exff Release 0.1.

A UML diagram of the Release 0.1 example model is shown in Figure 1.

Figure 1 - The Release 0.1 example UML model

The EXPRESS generated from the UML in Figure 1 follows.

SCHEMA pdm_example;

ENTITY product;
name : STRING ;
id : STRING ;
description : OPTIONAL STRING ;
END_ENTITY;

ENTITY product_category;
id : STRING ;
name : STRING ;
description : OPTIONAL STRING ;
END_ENTITY;

ENTITY product_definition_formation;
id : STRING ;
description : OPTIONAL STRING ;
of_product : product ;
END_ENTITY;

ENTITY product_related_product_category SUBTYPE OF ( product_category ) ;
products : SET [1:?] OF product ;
END_ENTITY;

END_SCHEMA;

Developing the UML Diagram

Warnings

Please note that ALL names chosen for UML concepts must be valid names in EXPRESS. No checking is done by the stylesheet or UML tool.

Use the template and save your new EXPRESS project

Once the UML tool is installed and tested so that you are capable of drawing and saving UML diagrams, the first step is to open the exff EXPRESS "template" file that is supplied with exff Release 0.1. This file should then be saved under a new name so that you do not write over it. This "template" project file has been tailored so that several EXPRESS concepts are built-in.

Name the schema

Setting the name of the EXPRESS schema to generate is handled by selecting the 'untitledSchema' UML Package and setting its name to be the desired schema name.

Any UML model element properly defined with this model as their 'Namespace' will appear in the resulting EXPRESS schema.

Create an entity data type

In order to create an entity data type, create a UML class a UML Class Diagram. Set the name of the UML class to be the desired entity data type name. Be sure to set the 'Namespace' of the UML class to be the UML model representing the EXPRESS schema.

Create a subtype declaration

In order to create an EXPRESS subtype declaration, create a UML generalization between the UML classes representing the EXPRESS subtype/supertype. The parent in the UML generalization is the EXPRESS supertype and the child is the EXPRESS subtype.

Create an abstract supertype

In order to create an EXPRESS ABSTRACT SUPERTYPE declaration, select the UML class representing the supertype and set its UML abstract flag. Its name will appear in italics on the diagram.

Create a simple explicit attribute

In order to create an EXPRESS explicit attribute, add a UML attribute to the UML class representing an entity data type. Set the name of the UML attribute to be the desired EXPRESS attribute. Set the type of the UML attribute to be the desired simple data type for the EXPRESS attribute.

If the EXPRESS explicit attribute should be optional, set multiplicity of the UML attribute to be '0..1'. Otherwise, set the multiplicity of the UML attribute to be '1..1'.

Create an explicit attribute reference

In order to create an EXPRESS explicit attribute that refers to an entity data type, create a UML association between the two UML classes representing the two EXPRESS entity data types. The UML multiplicity and association end names determine in which of the two resulting EXPRESS entity data types the explicit attribute appears.

Case 1 : By Naming (When one UML association end name = the association name)

Set the name of the UML association to be the desired EXPRESS explicit attribute name. Set the name of the UML association end at the target end of the relationship to be the desired EXPRESS explicit attribute name. Set the name of the UML association end at the source end of the relationship to another name or omit it entirely. The EXPRESS explicit attribute appears at the source end of the relationship.

Case 2 : By Multiplicity (When one UML class depends on the other for its existence)

Set the name of the UML association to be the desired EXPRESS explicit attribute name. Using this approach it is not necessary to name the UML association ends but it is good practice to do so. Using the convention from Case 1 is the safest approach as it will continue to produce valid EXPRESS even if the UML multiplicity is modified so that neither class depends on the other for its exisitence.

One UML class depending on another for its existence is specified by setting the lower bound of the UML multiplicity the dependent class to zero while setting it to one or more in the independent class. This causes the resulting EXPRESS explicit attribute to appear in the dependent entity data type.

If the upper bound of the UML multiplicity on the independent end of the association is greater than one, an EXPRESS SET is created as the domain of the explicit attribute.

If the UML multiplicity on the dependent end of the association is 0..1, then OPTIONAL is included in the EXPRESS explicit attribute.

If both association end lower bounds are zero nothing is created except as in Case 1. If both association end lower bounds are not zero nothing is created except as in Case 1. This is because it is not possible in these cases to use existence dependence to determine in which EXPRESS entity data type the explicit attribute should appear.

Transform the UML into EXPRESS

In order to transform the UML diagram, actually the underlying XMI file, into EXPRESS an XSLT stylesheet is used. The XMI file must first be extracted from the larger UML tool project file or exported using the UML tool itself. The Release 0.1 stylesheet uses an XPath function that also requires the DTD for the XMI file to be defined. Therefore, a DOCTYPE processing instruction must be added. OMG provides standard DTDs for these files.

<!DOCTYPE XMI SYSTEM "99-10-15.dtd"> must be added for the UML 1.3, XMI 1.0 files.

<!DOCTYPE XMI SYSTEM "01-02-16.dtd"> must be added for the UML 1.4, XMI 1.2 files.

Stylesheets are provided with exff Release 0.1 that add these doctypes to the UML XMI files. The DTD files are also provided. The 01-02-16_entity_fix.dtd file is modified as the OMG standard DTD presented problems with DTD ENTITY names containing colons using some XSLT transformation tools.