® A Proposed UML Profile For EXPRESS David Price Seattle 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 tools 1.allow alternative representations/notations 2.Constructs represented with semantics in UML that appear in XMI 1.i.e. not just notes on a diagram 3.Cannot require modifications to UML tools themselves 4.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-Requirememts 1.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 requirements 1.if it just can’t be done in UML, omit it 2.a subset of EXPRESS using UML is still useful 3.Need not be “executable” in any sense 4.Not trying to replace EXPRESS/EXPRESS-X tools 5.Entity instances out of scope 6.Not aligned with any particular x or other implementation standard at expense of others 1.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 > and > –primitive is a UML stereotype for datatypes –Primitive is a subclass of Datatype in the UML of UML 2.Adopt Java or XML Schema types 3.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 > stereotype USE/REFERENCE map to UML Dependency with > and > 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); > *Seattle: Ed Barkmeyer’s proposal for use/reference

® Entity Type and Subtype No change to Entity Type mapping except add > stereotype

® Non-constructed Defined Types No change to the Defined Type (not Constructed) except add > stereotype *Seattle: This needs namespace added string is not in same namespace as label.

® Enumeration Type No change to Enumeration Type mapping except > 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 > 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 > the code generation can treat these differently from > 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 consider 1.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 and > 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 >, > and

® 2. Aggregation by Constraint Model aggregations, including nested, as a single stereotyped UML association > –Constraint on association end encodes the LIST, SET, BAG, ARRAY and nesting >

® 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