®

A Proposed UML Profile For EXPRESS

David PriceSeattle ISO STEP Meeting

October 2004

®

EXPRESS and UML

• Goals– Define mechanisms enabling the definition of

EXPRESS schemas using UML constructs• Same mechanisms supported by UML diagram software• EXPRESS-G tools could output same constructs as XMI

– These same mechanisms support EXPRESS UML– Allows definition of UML Class and EXPRESS Entity

Type on same UML diagram maintaining distinction– An interim solution for UML 1.5 and EXPRESS 2 with

knowledge that UML 2 is coming and plans for a MOF 2 Metamodel of EXPRESS

– Provide a first step in fitting EXPRESS into OMG MDA

®

Requirements

1. Easily represented in most, if not all, UML tools1. allow alternative representations/notations

2. Constructs represented with semantics in UML that appear in XMI1. i.e. not just notes on a diagram

3. Cannot require modifications to UML tools themselves4. Acceptable to SC4 for use by modelers and for

publication in standards in same way EXPRESS-G is used today

5. Simplicity of use : make EXPRESS creation using UML as easy as possible for users

6. Support modeling, not only implementation as in P25 E1

®

Non-Requirememts1. Purity not driving requirements

1. OK to “bend the rules” of UML to make EXPRESS creation easier

2. OK to specify alternative representations, all UML tools may not support all UML constructs

2. Completeness not driving requirements1. if it just can’t be done in UML, omit it2. a subset of EXPRESS using UML is still useful

3. Need not be “executable” in any sense4. Not trying to replace EXPRESS/EXPRESS-X tools5. Entity instances out of scope6. Not aligned with any particular 10303-2x or other

implementation standard at expense of others1. Don’t make P28/XSD easy at expense of P21 or SDAI or

Java or C++

®

UML Profile constructs

• In UML, these are the “tools” with which this proposal is based– UML Stereotype– UML Tag Definitions and Tagged Value– UML Constraints

• From UML 1.5, Section 2.6 Extension Mechanisms:– The Extension Mechanisms package is the subpackage

that specifies how specific UML model elements are customized and extended with new semantics by using stereotypes, constraints, tag definitions, and tagged values. A coherent set of such extensions, defined for specific purposes, constitutes a UML profile (see Section 2.15, “Model Management,” on page 2-181).

®

More on Profiles (From UML 1.5)

• the ‘lightweight’ built-in extension mechanisms of UML– in contrast with the ‘heavyweight’ extensibility

mechanism as defined by the MOF specification

• there are restrictions on how UML profiles can extend the UML metamodel– restrictions are intended to ensure that any extensions

defined by a UML profile are purely additive– restrictions do not apply in the MOF context where, in

principle, any metamodel can be defined.• Consequently, every profile definition could also be

expressed as an MOF metamodel

• the XMI that they produce must be compatible with the predefined XMI for UML DTDs

®

UML Stereotype (From UML 1.5)

• Stereotypes– principle extension mechanism– a way of defining virtual subclasses of UML

metaclasses with new metaattributes and additional semantics

– must be strictly additive to the standard UML semantics

– a means for refining the standard semantics of UML– allow the modeler to add new modeling elements to

UML for use in creating models for process-specific or implementation language-specific domains (for example, supporting code generation for a certain language and infrastructure)

®

Meta-model of Extension Mechanisms

®

Characteristics of this Proposal

• Initial and incomplete– Try to get a baseline from which more detailed

work on the Profile can be developed

• Sufficient for STEP modules ARM– a good starting point– ARM is also the level at which “STEP UML” would

likely interface with the other UML models for Business Rules, Activity, Business Object, …

• Not sacred– only interest is getting a standard that works,

not on the details• e.g. what to call the stereotypes does not matter

®

Simple types

• Several ways of dealing with this– perhaps all should be allowed as the capabilities

in this area seem to vary from UML tool to UML tool

1. Stereotyped class <<primitive>> and <<exp_datatype>>– primitive is a UML stereotype for datatypes– Primitive is a subclass of Datatype in the UML of

UML

2. Adopt Java or XML Schema types3. Adopt native UML datatypes where we can

and add our others (e.g. Logical)4. other possibilities??

®

Schema and Interface Spec• Schema maps to UML Package with <<exp_schema>>

stereotype• USE/REFERENCE map to UML Dependency with

<<exp_use>> and <<exp_reference>> stereotypes

®

Schema and Interface Spec

®

Product_A

Product

Product_version_arm

Product_arm

SCHEMA Product_version_arm USE FROM Product_arm (Product as Product_A);

<<exp_use>>

*Seattle: Ed Barkmeyer’s proposal for use/reference

®

Entity Type and Subtype• No change to Entity Type mapping except add

<<exp_entity>> stereotype

®

Non-constructed Defined Types

• No change to the Defined Type (not Constructed) except add <<exp_type>> stereotype

*Seattle: This needs namespace addedstring is not in same namespace as label.

®

Enumeration Type• No change to Enumeration Type mapping except

<<exp_enum>> stereotype

*Seattle: look at ordered enum in OMG profile for java

®

Select Types

• Change to Select Type to map to UML Class as before adding <<exp_select>> stereotype

• Change link to select items from association named “selection_of” to unstereotyped UML Generalization– Could also add stereotype to Generalization but not proposing

to do so as that fact can be derived

®

Why Change Select Types Map?

• One rationale for previous mapping was “it creates multiple inheritance in many places” – but with <<exp_select>> the code generation can treat

these differently from <<exp_entity>>

• This approach seems closer to the idea of “union” of domains– Keeps possible EXPRESS<>UML<>OWL mapping in mind– OWL allows equivalent of “Entity1 = Entity2 UNION Entity

3”– That’s what “Entity1 = SELECT (Entity2, Entity 3)” says

too

®

Simple Explicit and Derived Attrs

• No change to simple explicit and dervied attribute mapping– Can’t see need to stereotype attributes too– Note : the expression for the derived is new, and may

not be modeled correctly

®

Aggregations

• Suggesting two approaches to consider1. Use stereotypes and a single approach for all

aggregation types• Issue was UML says “association is a set”, we should

overlook that statement… most implementations and UML tools do so

• existing approach for SET and UNIQUE LIST maps to UML Association

• change to map BAG, LIST and ARRAY to UML Association too

2. Treat as constraints on UML Association Ends– No “nesting in the UML diagram at all”

®

1. Aggregation by stereotype

• Minor change to SET or UNIQUE LIST mapping– Add stereotype to UML Association

<<exp_set> and <<exp_list>>

• Change to ARRAY, BAG and LIST not UNIQUE– In order to align these better with SET, map to

UML Association and stereotype the association as <<exp_array>>, <<exp_bag>> and <<exp_list>

®

2. Aggregation by Constraint

• Model aggregations, including nested, as a single stereotyped UML association <<exp_aggr>>– Constraint on association end encodes the LIST,

SET, BAG, ARRAY and nesting<<exp_aggregation>>

®

Proposed approach to development

• Approach to Part 25 Edition 2 development– Publish documentation of this with test suite of diagrams

and equivalent EXPRESS schemas on the Web– Get people with access to several different UML tools to

try to draw the test diagrams– Export XMI files and exchange among team for review– Do some proof-of-concept implementation based on those

XMI files– Hold workshop, conference call, whatever to address

issues raised during testing– Write CD document

• Goal is CD document out by end of the year and TS by June 2005