Issue 11154: Section: Abstractions (uml2-rtf) Source: MEGA International (Mr. Antoine Lonjon, alonjon(at)mega.com) Nature: Revision Severity: Critical Summary: Abstractions should support serialization by itself and interoperably with serialization of Constructs. In particular: - Package and Property should be available in Abstractions, to enable Abstractions to be used for serialization of typical models by itself. - There should be no circular dependencies between packages in Abstractions. - Constructs should only use imports from Abstractions, to enable models using Constructs to interoperate with models using only Abstractions. Package merge produces noninteroperable XSDs Resolution: Revised Text: Actions taken: July 16, 2007: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 16 Jul 2007 15:48:42 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Antoine Lonjon Company: MEGA International mailFrom: antoine.lonjon@mega.com Notification: Yes Specification: Unified Modeling Language: Infrastructure Section: Abstractions FormalNumber: formal/07-02-06 Version: RevisionDate: Page: Nature: Revision Severity: Critical HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) Description Abstractions should support serialization by itself and interoperably with serialization of Constructs. In particular: - Package and Property should be available in Abstractions, to enable Abstractions to be used for serialization of typical models by itself. - There should be no circular dependencies between packages in Abstractions. - Constructs should only use imports from Abstractions, to enable models using Constructs to interoperate with models using only Abstractions. Package merge produces noninteroperable XSDs. Subject: Response to issue 1154 Date: Wed, 8 Aug 2007 14:39:29 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Response to issue 1154 Thread-Index: AcfZnKUZwPuwlQ6EQOijho224rYGVQAG5oTg From: "LONJON Antoine" To: Cc: , Dear all, In issue 1154, I have expressed the need to use Core:Abstractions as a thin infrastructure for all non UML based specifications such as BPDM, BMM, OSM, SBVR. The following proposals makes a few change to Core:Abstractions in order to add packaging capabilities than are only available in Constructs. The proposal looks quite long because it includes all rewriting (most of them are copy from Constructs) that are done to Core:Abstractions. For the sake of model interoperability and complementary, it is essential that all specifications share this minimum Core set. Antoine **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** Issue 1154 - Resolution.doc OMG Issue No: 11154 Title: Abstractions should support serialization by itself Source: Antoine Lonjon, MEGA International (Antoine.lonjon@mega.com) Summary: Abstractions should support serialization by itself and interoperably with serialization of Constructs. In particular: - Abstractions should support serialization by itself and interoperably with serialization of Constructs. In particular: - Package and Property should be available in Abstractions, to enable Abstractions to be used for serialization of typical models by itself. - There should be no circular dependencies between packages in Abstractions. - Constructs should only use imports from Abstractions, to enable models using Constructs to interoperate with models using only Abstractions. Package merge produces noninteroperable XSDs. Resolution: This resolution addresses issues 11154, 11155. Most of the resolution is repackaging to bring some capabilities from Constructs into Abstractions. One new element is introduced (ImportableElement in Abstractions). In particular, this resolution proposes two changes: 1. Move Constructs Package and Property into Abstractions. This requires bringing Namespaces from Constructs into Abstractions. 2. Separate Namespace and Package to remove circular dependency. This requires introducing ImportableElement. Specifically, to address the Package issues above: 1. Move the entire Namespaces diagram in Constructs to Namespaces package in Abstractions. 2. Introduce a new class called .ImportableElement. in Abstractions::Namespaces that takes the place of PackageableElement. It generalizes PackageableElement in Abstractions::Packages. 3. Remove the Visibilities package from Core:Abstractions 4. Move all elements of the Packages diagram in Constructs, except PackageMerge to a new .Packages. package in Abstractions. 5. Move PackageImport and PackageableElement from Abstraction::Namespaces to Abstraction::Packages. 6. PackageableElement generalizes Type in Abstractions. PackageableElement generalizes Constraint in Abstractions. 7. Add a new merges between Constructs and Abstractions::Packages. 8. Change package merge between Constructs and Abstractions::Namespaces to an import. 9. Remove package merge from Constructs to Basics To address the Property issues above: 10. Merge the Changeabilities package into the StructuralFeatures package 11. Add a new .Properties. package in Abstractions that contains Property. 12. Add a new .Datatypes. package in Abstractions that has the content of the Datatype Diagram of Constructs, except the associations with Operations. 13. Add a new merges between Constructs and Abstractions::Properties. 14. Add a new merges between Constructs and Abstractions::Datatypes. Revised Text for: 1. Move the entire Namespaces diagram in Constructs to Namespaces package in Abstractions. 2. Introduce a new class called .ImportableElement. in Abstractions::Namespaces that takes the place of PackageableElement. It generalizes PackageableElement in Abstractions::Packages. Figure 9.2 is changed by the following to reflect the change of import dependencies between Abstractions packages Figure 1 - The Abstractions package contains several subpackages, all of which are specified in this chapter Figure 9.37 is updated as follow Figure xxx - The Packages package Figure 9.38 is updated as follow Figure 2 - The Namespaces diagram of the Namespaces package The description of ElementImport in section 9.14.2 in updated as follow (elements in red): 9.14.1 ElementImport An element import identifies an element in another packagenamespace, and allows the element to be referenced using its name without a qualifier. Description An element import is defined as a directed relationship between an importing namespace and an packageable importable element. The name of the packageable importable element or its alias is to be added to the namespace of the importing namespace. It is also possible to control whether the imported element can be further imported. Generalizations . .DirectedRelationship. from Relationships Attributes . visibility: VisibilityKind Specifies the visibility of the imported PackageableElement within the importing Package. The default visibility is the same as that of the imported element. If the imported element does not have a visibility, it is possible to add visibility to the element import; default value is public. . alias: String [0..1] Specifies the name that should be added to the namespace of the importing Package in lieu of the name of the imported PackagableElementImportableElement. The aliased name must not clash with any other member name in the importing Package. By default, no alias is used. Associations . importedElement: PackageableElement ImportableElement [1] Specifies the PackageableElement ImportableElement whose name is to be added to a Namespace. Subsets DirectedRelationship::target. . importingNamespace: Namespace [1] Specifies the Namespace that imports a PackageableElement ImportableElement from another Package. Subsets DirectedRelationship::source and Element::owner. Constraints [1] The visibility of an ElementImport is either public or private. self.visibility = #public or self.visibility = #private [2] An importedElement has either public visibility or no visibility at all. self.importedElement.visibility.notEmpty() implies self.importedElement.visibility = #public Additional Operations [1] The query getName() returns the name under which the imported PackageableElement ImportableElement will be known in the importing namespace. ElementImport::getName(): String; getName = if self.alias->notEmpty() then self.alias elseself.importedElement.name endif Semantics An element import adds the name of a packageable importable element from a namespace to the importing namespace. It works by reference, which means that it is not possible to add features to the element import itself, but it is possible to modify the referenced element in the namespace from which it was imported. An element import is used to selectively import individual elements without relying on a package import. In case of a nameclash with an outer name (an element that is defined in an enclosing namespace is available using its unqualified name in enclosed namespaces) in the importing namespace, the outer name is hidden by an element import, and the unqualified name refers to the imported element. The outer name can be accessed using its qualified name. If more than one element with the same name would be imported to a namespace as a consequence of element imports or package imports, the elements are not added to the importing namespace and the names of those elements must be qualified in order to be used in that namespace. If the name of an imported element is the same as the name of an element owned by the importing namespace, that element is not added to the importing namespace and the name of that element must be qualified in order to be used. If the name of an imported element is the same as the name of an element owned by the importing namespace, the name of the imported element must be qualified in order to be used and is not added to the importing namespace. An imported element can be further imported by other namespaces using either element or package imports. The visibility of the ElementImport may be either the same or more restricted than that of the imported element. 9.14.2 Importable Element An importable element indicates a named element that can be imported by a namespace. Description An importable element indicates a named element that can be imported by a namespace. Generalizations . .NamedElement. from Namespaces Attributes No additional attributes Associations No additional associations Constraints No additional constraints Semantics No additional semantics Notation No additional notation The description of NamedElement in section 9.14.1 in updated as follow (elements in red): 9.14.1 NamedElement A named element is an element in a model that may have a name. Description A named element represents elements that may have a name. The name is used for identification of the named element within the namespace in which it is defined. A named element also has a qualified name that allows it to be unambiguously identified within a hierarchy of nested namespaces. NamedElement has a visibility attribute. NamedElement is an abstract metaclass. Generalizations . .Element (as specialized). on page 74from Comments Attributes . name: String [0..1] The name of the NamedElement . / qualifiedName: String [0..1] A name which allows the NamedElement to be identified within a hierarchy of nested Namespaces. It is constructed from the names of the containing namespaces starting at the root of the hierarchy and ending with the name of the NamedElement itself. This is a derived attribute. . visibility: VisibilityKind [0..1] Determines where the NamedElement appears within different Namespaces within the overall model, and its accessibility. Associations . / namespace: Namespace [0..1] Specifies the namespace that owns the NamedElement. Subsets Element::owner. This is a derived union. Constraints [1] If there is no name, or one of the containing namespaces has no name, there is no qualified name. (self.name->isEmpty() or self.allNamespaces()->select(ns | ns.name->isEmpty())->notEmpty()) implies self.qualifiedName->isEmpty() [2] When there is a name, and all of the containing namespaces have a name, the qualified name is constructed from the names of the containing namespaces. (self.name->notEmpty() and self.allNamespaces()->select(ns | ns.name->isEmpty())->isEmpty()) implies self.qualifiedName = self.allNamespaces()->iterate( ns : Namespace; result: String = self.name | ns.name->union(self.separator())->union(result)) [1] If a NamedElement is not owned by a Namespace, it does not have a visibility. namespace->isEmpty() implies visibility->isEmpty() Additional Operations [1] The query allNamespaces() gives the sequence of namespaces in which the NamedElement is nested, working outwards. NamedElement::allNamespaces(): Sequence(Namespace); allNamespaces = if self.namespace->isEmpty() then Sequence{} else self.namespace.allNamespaces()->prepend(self.namespace) endif [2] The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have unrelated types or (b) they have related types but different names. NamedElement::isDistinguishableFrom(n:NamedElement, ns: Namespace): Boolean; isDistinguishable =if self.oclIsKindOf(n.oclType) or n.oclIsKindOf(self.oclType) then ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty() else true endif [3] The query separator() gives the string that is used to separate names when constructing a qualified name. NamedElement::separator(): String; separator = .::. Semantics The name attribute is used for identification of the named element within namespaces where its name is accessible. Note that the attribute has a multiplicity of [ 0..1 ], which provides for the possibility of the absence of a name (which is different from the empty name). The visibility attribute provides the means to constrain the usage of a named element either in namespaces or in access to the element. It is intended for use in conjunction with import, generalization, and access mechanisms. The description of Namespace in section 9.14.2 in updated as follow (elements in red): 9.14.3 Namespace A namespace is an element in a model that contains a set of named elements that can be identified by name. Description A namespace is a named element that can own other named elements. Each named element may be owned by at most one namespace. A namespace provides a means for identifying named elements by name. Named elements can be identified by name in a namespace either by being directly owned by the namespace or by being introduced into the namespace by other means (e.g., importing or inheriting). A namespace has the ability to import individual member thereby making it possible to refer to those named elements without qualification in the importing namespace. In the case of conflicts, it is necessary to use qualified names or aliases to disambiguate the referenced elements. Namespace is an abstract metaclass. The Generalization section in section 9.14.2 in updated as follow (elements in red): Generalizations . .Namespace. on page 71.NamedElement. from Namespaces The Associations section in section 9.14.2 in updated as follow (elements in red): Associations .elementImport: ElementImport [*] References the ElementImports owned by the Namespace.Subsets Element::ownedElement. . /importedMember: ImportableElement [*] References the ImportableElements that are members of this Namespace as a result of ElementImports. Subsets Namespace::member. This is a derived property. . / member: NamedElement [*] A collection of NamedElements identifiable within the Namespace, either by being owned or by being introduced by importing or inheritance. This is a derived union. . / ownedMember: NamedElement [*] A collection of NamedElements owned by the Namespace. Subsets Element::ownedElement and Namespace::member. This is a derived union. The Constraints section in section 9.14.2 in updated as follow (elements in red): Constraints [1] If there is no name, or one of the containing namespaces has no name, there is no qualified name. (self.name->isEmpty() or self.allNamespaces()->select(ns | ns.name->isEmpty())->notEmpty()) implies self.qualifiedName->isEmpty() [2] When there is a name, and all of the containing namespaces have a name, the qualified name is constructed from the names of the containing namespaces. (self.name->notEmpty() and self.allNamespaces()->select(ns | ns.name->isEmpty())->isEmpty()) implies self.qualifiedName = self.allNamespaces()->iterate( ns : Namespace; result: String = self.name | ns.name->union(self.separator())->union(result)) [3] The importedMember property is derived from the ElementImports and the PackageImports. self.importedMember->includesAll(self.importMembers(self.elementImport.importedElement.asSet())) The .Additional Operations. section in section 9.14.2 in updated as follow (elements in red): Additional operations [1] The query getNamesOfMember() gives a set of all of the names that a member would have in a Namespace. In general a member can have multiple names in a Namespace if it is imported more than once with different aliases. Those semantics are specified by overriding the getNamesOfMember operation. The specification here simply returns a set containing a single name, or the empty set if no name. The operation also takes account of importing. It gives back the set of names that an element would have in an importing namespace, either because it is owned; or if not owned, then imported individually. Namespace::getNamesOfMember(element: NamedElement): Set(String); getNamesOfMember = if member->includes(element) then Set{}->including(element.name) else Set{} endif Namespace::getNamesOfMember(element:NamedElement):Set(String); getNamesOfMember= if self.ownedMember ->includes(element) then Set{}->include(element.name) else let elementImports:ElementImport=self.elementImport-> select(ei|ei.importedElement = element) in if elementImports->notEmpty() then elementImports->collect(el|el.getName()) endif endif [2] and [3] are identical [4] The query importMembers() defines which of a set of ImportableElements are actually imported into the namespace. This excludes hidden ones, i.e., those which have names that conflict with names of owned members, and also excludes elements that would have the same name when imported. Namespace::importMembers(imps: Set(ImportableElement)):Set(ImportableElement); importMembers = self.excludeCollisions(imps)->select(imp | self.ownedMember->forAll(mem | mem.imp.isDistinguishableFrom(mem, self))) [5] The query excludeCollisions() excludes from a set of ImportableElements any that would not be distinguishable from each other in this namespace. Namespace::excludeCollisions(imps: Set(ImportableElements)): Set(ImportableElements); excludeCollisions = imps->reject(imp1 | imps.exists(imp2 | not imp1.isDistinguishableFrom(imp2, self))) The .Semantic. section in section 9.14.2 in updated as follow (elements in red): Semantics A namespace provides a container for named elements. It provides a means for resolving composite names, such as name1::name2::name3. The member association identifies all named elements in a namespace called N that can be referred to by a composite name of the form N::. Note that this is different from all of the names that can be referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces. Named elements may appear within a namespace according to rules that specify how one named element is distinguishable from another. The default rule is that two elements are distinguishable if they have unrelated types, or related types but different names. This rule may be overridden for particular cases, such as operations that are distinguished by their signature. An element import is used to selectively import individual elements. An element import adds the name of an Importable element to the importing namespace. It works by reference, which means that it is not possible to add features to the element import itself, but it is possible to modify the referenced element in the namespace from which it was imported. In case of a nameclash with an outer name (an element that is defined in an enclosing namespace is available using its unqualified name in enclosed namespaces) in the importing namespace, the outer name is hidden by an element import, and the unqualified name refers to the imported element. The outer name can be accessed using its qualified name. If more than one element with the same name would be imported to a namespace as a consequence of element imports, the elements are not added to the importing namespace and the names of those elements must be qualified in order to be used in that namespace. If the name of an imported element is the same as the name of an element owned by the importing namespace, that element is not added to the importing namespace and the name of that element must be qualified in order to be used. If the name of an imported element is the same as the name of an element owned by the importing namespace, the name of the imported element must be qualified in order to be used and is not added to the importing namespace. An imported element can be further imported by other namespaces using element imports. The visibility of the ElementImport may be either the same or more restricted than that of the imported element. The description of Namespace in section 9.14.2 in updated as follow (elements in red): 9.14.3 Namespace A namespace is an element in a model that contains a set of named elements that can be identified by name. Description A namespace is a named element that can own other named elements. Each named element may be owned by at most one namespace. A namespace provides a means for identifying named elements by name. Named elements can be identified by name in a namespace either by being directly owned by the namespace or by being introduced into the namespace by other means (e.g., importing or inheriting). A namespace has the ability to import individual member thereby making it possible to refer to those named elements without qualification in the importing namespace. In the case of conflicts, it is necessary to use qualified names or aliases to disambiguate the referenced elements. Namespace is an abstract metaclass. Revised Text for: 1. Move all elements of the Packages diagram in Constructs, except PackageMerge to a new .Packages. package in Abstractions. 2. Move PackageImport and PackageableElement from Abstraction::Namespaces to Abstraction::Packages. A new section 9.22 .Packages. package is added as follow 9.22 Packages Package The Packages subpackage of the Abstractions package specifies the Package constructs. Figure xxx - The Packages package Figure xxx - The elements defined in the Packages package 9.22.1 Package A package is used to group elements, and provides a namespace for the grouped elements. Description A package is a namespace for its members, and may contain other packages. Only packageable elements can be owned members of a package. By virtue of being a namespace, a package can import either individual members of other packages. Generalizations . .PackageableElement. on page 148 from Packages . .Namespace. on page 147from Namespaces Attributes No additional attributes Associations . /nestedPackage: Package [*] References the owned members that are Packages. Subsets Package::ownedMember and . ownedMember: PackageableElement [*] Specifies the members that are owned by this Package. Subset s Namespace::ownedMember. . package: Package [0..1] References the owning package of a package. Subsets NamedElement::namespace and redefines Basic::Package::nestingPackage. Constraints [1] If an element that is owned by a package has visibility, it is public or private. self.ownedElements->forAll(e | e.visibility->notEmpty() implies e.visibility = #public or e.visibility = #private) Additional Operations [1] The query mustBeOwned() indicates whether elements of this type must have an owner. Package::mustBeOwned() : Boolean mustBeOwned = false [2] The query visibleMembers() defines which members of a Package can be accessed outside it. Package::visibleMembers() : Set(PackageableElement); visibleMembers = member->select( m | self.makesVisible(m)) [3] The query makesVisible() defines whether a Package makes an element visible outside itself. Elements with no visibility and elements with public visibility are made visible. Package::makesVisible(el: Namespaces::NamedElement) : Boolean; pre: self.member-> includes(el) makesVisible = -- the element is in the package (ownedMember->includes(el)) or -- it is imported individually with public visibility (elementImport-> select(ei|ei.visibility = #public)-> collect(ei|ei.importedElement)->includes(el)) or -- it is imported through a package with public visibility (packageImport-> select(pi|pi.visibility = #public)-> collect(pi| pi.importedPackage.member->includes(el))->notEmpty()) Semantics A package is a namespace and is also a packageable element that can be contained in other packages. The elements that can be referred to using non-qualified names within a package are owned elements, imported elements, and elements in enclosing (outer) namespaces. Owned and imported elements may each have a visibility that determines whether they are available outside the package. A package owns its owned members, with the implication that if a package is removed from a model, so are the elements owned by the package. The public contents of a package are always accessible outside the package through the use of qualified names. Notation A package is shown as a large rectangle with a small rectangle (a .tab.) attached to the left side of the top of the large rectangle. The members of the package may be shown within the large rectangle. Members may also be shown by branching lines to member elements, drawn outside the package. A plus sign (+) within a circle is drawn at the end attached to the namespace (package). . If the members of the package are not shown within the large rectangle, then the name of the package should be placed within the large rectangle. . If the members of the package are shown within the large rectangle, then the name of the package should be placed within the tab. The visibility of a package element may be indicated by preceding the name of the element by a visibility symbol (.+. for public and .-. for private). Package elements with defined visibility may not have protected or package visibility. Presentation Options A tool may show visibility by a graphic marker, such as color or font. A tool may also show visibility by selectively displaying those elements that meet a given visibility level (e.g., only public elements). A diagram showing a package with contents must not necessarily show all its contents; it may show a subset of the contained elements according to some criterion. Elements that become available for use in an importing package through a package import or an element import may have a distinct color or be dimmed to indicate that they cannot be modified. Examples There are three representations of the same package Types in Figure 11.27. The one on the left just shows the package without revealing any of its members. The middle one shows some of the members within the borders of the package, and the one to the right shows some of the members using the alternative membership notation. 9.22.2 PackageableElement A packageable element indicates an named importable element that may be owned directly by a package. Description A packageable element indicates an named importable element that may be owned directly by a package. Generalizations . .NamedElement..ImportableElement. on page 146from Namespaces Attributes No additional attributes Associations No additional associations Constraints No additional constraints Semantics No additional semantics Notation No additional notation 9.22.3 PackageImport Description A package import is defined as a directed relationship that identifies a package whose members are to be imported by a namespacepackage. Generalizations . .DirectedRelationship. from Relationships . .DirectedRelationship. on page 104 Attributes . visibility: VisibilityKind Specifies the visibility of the imported PackageableElements within the importing NamespacePackage, i.e., whether imported elements will in turn be visible to other packages that use that importingPackage as an importedPackage. If the PackageImport is public, the imported elements will be visible outside the package, while if it is private they will not. By default, the value of visibility is public. Associations . importedPackage: Package [1] Specifies the Package whose members are imported into a NamespacePackage. Subsets DirectedRelationship::target. . importingNamespace: Namespace Package [1] Specifies the Namespace Package that imports the members from a Package. Subsets DirectedRelationship::source and Element::owner. Constraints [1] The visibility of a PackageImport is either public or private. self.visibility = #public or self.visibility = #private Semantics A package import is a relationship between an importing packagenamespace and another package, indicating that the importing namespace package adds the names of the members of the package to its own namespace. Conceptually, a package import is equivalent to having an element import to each individual member of the imported packagenamespace, unless there is already a separately-defined element import. Notation A package import is shown using a dashed arrow with an open arrowhead from the importing package to the imported package. A keyword is shown near the dashed arrow to identify which kind of package import that is intended. The predefined keywords are «import» for a public package import, and «access» for a private package import. Presentation options As an alternative to the dashed arrow, it is possible to show an element import by having a text that uniquely identifies the imported element within curly brackets either below or after the name of the namespace. The textual syntax is then: .{.import . .}. | .{access . .}. Examples In Figure 11.24, a number of package imports are shown. The elements in Types are imported to ShoppingCart, and then further imported WebShop. However, the elements of Auxiliary are only accessed from ShoppingCart, and cannot be referenced using unqualified names from WebShop. Revised Text for: 5. PackageableElement generalizes Type in Abstractions. Figure 9.50 is changed by the following to reflect the change of import dependencies of TypedElements Figure 9.50 - The TypedElements package Figure 9.51 - The elements defined in the TypedElements package Sub-section .Generalizations. of section 9.20.1 is changed as follows: Generalizations . .NamedElement. on page 71.PackageableElement. from Packages Revised Text for: 8. Merge the Changeabilities package into the StructuralFeatures package Figure 9.46 is changed by the following Figure 9.46 - The elements defined in the StructuralFeatures package Revised Text for: 9. Add a new .Properties. package in Abstractions that contains Property. The Properties package of the Abstractions package provides mechanisms for specifying properties Figure xxx - The Properties package Figure xxx - The elements defined in the Properties package 11.3.5 Property A property is a structural feature of a classifier that characterizes instances of the classifier. Constructs::Property merges the definition of Basic::Property with Constructs::StructuralFeature. A property related by ownedAttribute to a classifier (other than an association) represents an attribute and might also represent an association end. It relates an instance of the class to a value or set of values of the type of the attribute. A property related by memberEnd or its specializations to an association represents an end of the association. The type of the property is the type of the end of the association. Description Property represents a declared state of one or more instances in terms of a named relationship to a value or values. When a property is an attribute of a classifier, the value or values are related to the instance of the classifier by being held in slots of the instance. When a property is an association end, the value or values are related to the instance or instances at the other end(s) of the association (see semantics of Association). Property is indirectly a subclass of Constructs::TypedElement. The range of valid values represented by the property can be controlled by setting the property.s type. Attributes . isDerived : Boolean If isDerived is true, the value of the attribute property is derived from information elsewhere. The default value is false. . isDerivedUnion : Boolean Specifies whether the property is derived as the union of all of the properties that are constrained to subset it. The default value is false. . isReadOnly : Boolean This redefines the corresponding attribute in Basic::Property and Abstractions::StructuralFeature. The default value is false. . default : String [0..1] A string that is evaluated to give a default value for the attribute when an object of the owning class is instantiated. . isComposite : Boolean If isComposite is true, the object containing the attribute property is a container for the object or value contained in the attributeproperty. The default value is false. Associations . subsettedProperty : Property [*] References the properties of which this property is constrained to be a subset. Constraints [21] A specialization of a composite aggregation is also a composite aggregation.A multiplicity of a composite aggregation must not have an upper bound greater than 1. isComposite implies (upperBound()->isEmpty() or upperBound() <= 1) [23] Subsetting may only occur when the context of the subsetting property conforms to the context of the subsetted property. subsettedProperty->notEmpty() implies (subsettingContext()->notEmpty() and subsettingContext()->forAll (sc | subsettedProperty->forAll(sp | sp.subsettingContext()->exists(c | sc.conformsTo(c))))) [35] A subsetting property may strengthen the type of the subsetted property, and its upper bound may be less. subsettedProperty->forAll(sp | type.conformsTo(sp.type) and ((upperBound()->notEmpty() and sp.upperBound()->notEmpty()) implies upperBound()<=sp.upperBound() )) [47] A derived union is derived. isDerivedUnion implies isDerived [58] A derived union is read only isDerivedUnion implies isReadOnly [69] The value of isComposite is true only if aggregation is composite. isComposite = (self.aggregation = #composite) [107] A Property cannot be subset by a Property with the same name if (self.subsettedProperty->notEmpty()) then self.subsettedProperty->forAll(sp | sp.name <> self.name) Additional Operations [1] The query subsettingContext() gives the context for subsetting a property. It consists, in the case of an attribute, of the corresponding classifier, and in the case of an association end, all of the classifiers at the other ends. Property::subsettingContext() : Set(Type) subsettingContext = if association->notEmpty() then association.endType-type else if classifier->notEmpty() then Set{classifier} else Set{} endif endif Revised Text for: 10. Add a new .Datatypes. package in Abstractions that has the content of the Datatype Diagram of Constructs, except the associations with Operations. A new section 9.23 .Datatypes. package is added as follow 9.22 Datatypes Package Figure xxx - The Properties package Figure xxx - The elements defined in the Datatypes package 9.22.1 DataType Description A data type is a type whose instances are identified only by their value. A DataType may contain attributes to support the modeling of structured data types. A typical use of data types would be to represent programming language primitive types or CORBA basic types. For example, integer and string types are often treated as data types. Generalizations . .Classifier. on page 127 Attributes No additional attributes Associations . ownedAttribute: Property[*] The Attributes owned by the DataType. This is an ordered collection. Subsets Classifier::attribute feature and Element::ownedMember. Constraints No additional constraints Semantics A data type is a special kind of classifier, similar to a class which . It differs from a class in that instances of a data type are identified only by their value. All copies of an instance of a data type and any instances of that data type with the same value are considered to be the same instance. Instances of a data type that has attributes (i.e., is a structured data type) are considered to be the same if the structure is the same and the values of the corresponding attributes are the same. If a data type has attributes, then instances of that data type will contain attribute values matching the attributes. Semantic Variation Points Any restrictions on the capabilities of data types, such as constraining the types of their attributes, is a semantic variation point. Notation A data type is shown using the classifier symbol with keyword «dataType» or when it is referenced by e.g., an attribute, shown as a string containing the name of the data type. Examples Figure 11.19 - Notation of data type: to the left is an icon denoting a data type and to the right is a reference to a data type that is used in an attribute 9.22.2 Enumeration An enumeration is a data type whose values are enumerated in the model as enumeration literals. Description Constructs::Enumeration reuses the definition of Enumeration from Basic. It adds a specialization to Constructs::DataType. Enumeration is a kind of data type, whose instances may be any of a number of predefined enumeration literals. It is possible to extend the set of applicable enumeration literals in other packages or profiles. Generalizations . .DataType. on page 134from Datatypes.. Attributes No additional attributes Associations . ownedLiteral: EnumerationLiteral[*] The ordered set of literals for this Enumeration. Subsets Element::ownedMember. Constraints No additional constraints Semantics The run-time instances of an Enumeration are data values. Each such value corresponds to exactly one EnumerationLiteral. Notation An enumeration may be shown using the classifier notation (a rectangle) with the keyword «enumeration». The name of the enumeration is placed in the upper compartment. A compartment listing the attributes for the enumeration is placed below the name compartment. A compartment listing the operations for the enumeration is placed below the attribute compartment. A list of enumeration literals may be placed, one to a line, in the bottom compartment. The attributes and operations compartments may be suppressed, and typically are suppressed if they would be empty. Examples Figure xxx - Example of an enumeration EnumerationLiteral An enumeration literal is a user-defined data value for an enumeration. Description Constructs:: An enumeration literal is a value of an enumeration.EnumerationLiteral reuses the definition of Enumeration from Basic. It adds a specialization to Constructs::NamedElement. Generalizations . .NamedElement. on page 143from Namespaces Attributes No additional attributes Associations . enumeration: Enumeration[0..1] The Enumeration that this EnumerationLiteral is a member of. Subsets NamedElement::namespace. Constraints No additional constraints Semantics An EnumerationLiteral defines an element of the run-time extension of an enumeration data type. An EnumerationLiteral has a name that can be used to identify it within its enumeration datatype. The enumeration literal name is scoped within and must be unique within its enumeration. Enumeration literal names are not global and must be qualified for general use. The run-time values corresponding to enumeration literals can be compared for equality. Notation An EnumerationLiteral is typically shown as a name, one to a line, in the compartment of the enumeration notation. See .Enumeration.. Examples See .Enumeration. 9.22.3 PrimitiveType A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically. A primitive type is a data type implemented by the underlying infrastructure and made available for modeling. Description A primitive type is a data type implemented by the underlying infrastructure and made available for modeling.Constructs::PrimitiveType reuses the definition of PrimitiveType from Basic. It adds a specialization to Constructs::DataType. The instances of primitive type used in UML itself include Boolean, Integer, UnlimitedNatural, and String (see Chapter 12, .Core::PrimitiveTypes.). Generalizations . .DataType. on page 134from Datatypes. Attributes No addtional attributes Associations No additional associations Constraints No additional constraints Semantics The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML Infrastructure (for example, the various integers). Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable. Notation A primitive type has the keyword «primitive» above or before the name of the primitive type. Instances of the predefined primitive types (see Chapter 12, .Core::PrimitiveTypes.) may be denoted with the same notation as provided for references to such instances (see the subtypes of .ValueSpecification.). Examples See Chapter 12, .Core::PrimitiveTypes. for examples. Revised Text for: 12. Add a new merges between Constructs and Abstractions::Packages. 13. Change package merge between Constructs and Abstractions::Namespaces to an import. 14. Remove package merge from Constructs to Basics Figure 11.2 is updated as follow Figure 11.2 - The Constructs package depends on several other packages Disposition: Resolved To: "LONJON Antoine" , uml2-rtf@omg.org Cc: bmm-ftf@omg.org, bpdm-ftf@omg.org Subject: Re: Response to issue 1154 -- PLEASE REVIEW X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Thu, 9 Aug 2007 09:39:22 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 08/09/2007 09:39:23, Serialize complete at 08/09/2007 09:39:23 Thanks, Antoine. I would like to draw the RTF's attention to this proposed resolution by Antoine because it may have a significant impact on current UML 2 implementations. In particlar, I would like to hear from vendors and the impact that they feel this might have on their implementations and customers. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "LONJON Antoine" 08/08/2007 08:39 AM To cc , Subject Response to issue 1154 Dear all, In issue 1154, I have expressed the need to use Core:Abstractions as a thin infrastructure for all non UML based specifications such as BPDM, BMM, OSM, SBVR. The following proposals makes a few change to Core:Abstractions in order to add packaging capabilities than are only available in Constructs. The proposal looks quite long because it includes all rewriting (most of them are copy from Constructs) that are done to Core:Abstractions. For the sake of model interoperability and complementary, it is essential that all specifications share this minimum Core set. Antoine **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** [attachment "Issue 1154 - Resolution.doc" deleted by Branislav Selic/Ottawa/IBM] X-Virus-Scanned: by amavisd-new at softeam.com From: "Desfray" To: "'Branislav Selic'" , "'LONJON Antoine'" , Cc: , Subject: RE: Response to issue 1154 -- PLEASE REVIEW Date: Thu, 9 Aug 2007 16:04:57 +0200 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfajGBXeKW/o78+QeWOW1Mnk9xTUwAAY+Ig Dear all, I would support this proposal. >>>> For the sake of model interoperability and complementary, it is essential that all specifications share this minimum Core set. That is a fair goal for OMG, isn.t it? I think that reorganizing a bit packages does not impact tools (that is an easy burden for our Objecteering modelling & MDA tool). Best regards ========================================= Philippe Desfray VP for R&D - SOFTEAM 21 Avenue Victor Hugo - 75016 PARIS 0153968400 phd@softeam.fr www.softeam.com - www.objecteering.com -------------------------------------------------------------------------------- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : jeudi 9 août 2007 15:39 À : LONJON Antoine; uml2-rtf@omg.org Cc : bmm-ftf@omg.org; bpdm-ftf@omg.org Objet : Re: Response to issue 1154 -- PLEASE REVIEW Importance : Haute Thanks, Antoine. I would like to draw the RTF's attention to this proposed resolution by Antoine because it may have a significant impact on current UML 2 implementations. In particlar, I would like to hear from vendors and the impact that they feel this might have on their implementations and customers. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "LONJON Antoine" 08/08/2007 08:39 AM To cc , Subject Response to issue 1154 Dear all, In issue 1154, I have expressed the need to use Core:Abstractions as a thin infrastructure for all non UML based specifications such as BPDM, BMM, OSM, SBVR. The following proposals makes a few change to Core:Abstractions in order to add packaging capabilities than are only available in Constructs. The proposal looks quite long because it includes all rewriting (most of them are copy from Constructs) that are done to Core:Abstractions. For the sake of model interoperability and complementary, it is essential that all specifications share this minimum Core set. Antoine **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** [attachment "Issue 1154 - Resolution.doc" deleted by Branislav Selic/Ottawa/IBM] Subject: RE: Response to issue 1154 -- PLEASE REVIEW Date: Thu, 9 Aug 2007 10:21:52 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Response to issue 1154 -- PLEASE REVIEW Thread-Index: AcfajEdqm+Rfinn7S9il+15G7SwcZAAArPcQ From: "Frank, Karl (Mission Systems)" To: "Branislav Selic" , "LONJON Antoine" , Cc: , X-OriginalArrivalTime: 09 Aug 2007 14:21:55.0103 (UTC) FILETIME=[A32B7AF0:01C7DA90] This email is to support Antoine's suggestions based on two development experiences: 1. BPDM I was working with the BPDM submission team while Antoine was wrestling with the task of defining a metamodel for BPMN and BPDM and observed how the infrastructure library failed to fulfill its stated purpose of providing a reusable basis for language specification, because of too-tight coupling with UML 2. I think we all recognize that maintenance of the infrastructure has been organizationally merged with maintenance of UML 2.x, and to make it serve its purpose, we need to pay close attention to Antoine's experience, which is our only real review of the Infrastructure per se. 2. Together encompassing 3 OMG languages in one produc I was one of the architects of the Together product a few years ago, and that product supported not just UML 2.0 (about 75% of the mm) but also UML 1.4 and BPMN. We needed to define a higher-level metamodel that could be used to cover all three of these OMG languages. We followed the principle that this metamodel needed to be something distinct from the metamodel specific to any one of the 3, and we found that the infrastructure library could not serve our purposes, it was too geared to UML 2. Both these experiences tend to show that UML Infrastructure needs serious attention if it is to serve its purpose. If we don't give it that attention, we might as well just extract the bit that UML 2 uses and merge it with the superstructure spec. Cordially yours, Karl Frank General Scientist, Mission Systems Northrop-Grumman Corporation GMT-5 (EDT, EST) cell: +1 978 853 3592 -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 09, 2007 9:39 AM To: LONJON Antoine; uml2-rtf@omg.org Cc: bmm-ftf@omg.org; bpdm-ftf@omg.org Subject: Re: Response to issue 1154 -- PLEASE REVIEW Importance: High Thanks, Antoine. I would like to draw the RTF's attention to this proposed resolution by Antoine because it may have a significant impact on current UML 2 implementations. In particlar, I would like to hear from vendors and the impact that they feel this might have on their implementations and customers. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "LONJON Antoine" 08/08/2007 08:39 AM To cc , Subject Response to issue 1154 Dear all, In issue 1154, I have expressed the need to use Core:Abstractions as a thin infrastructure for all non UML based specifications such as BPDM, BMM, OSM, SBVR. The following proposals makes a few change to Core:Abstractions in order to add packaging capabilities than are only available in Constructs. The proposal looks quite long because it includes all rewriting (most of them are copy from Constructs) that are done to Core:Abstractions. For the sake of model interoperability and complementary, it is essential that all specifications share this minimum Core set. Antoine **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** [attachment "Issue 1154 - Resolution.doc" deleted by Branislav Selic/Ottawa/IBM] Subject: RE: Response to issue 1154 -- PLEASE REVIEW Date: Tue, 4 Sep 2007 12:34:22 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Response to issue 1154 -- PLEASE REVIEW Thread-Index: AcfajEdqm+Rfinn7S9il+15G7SwcZAAArPcQBRPRZKA= From: "LONJON Antoine" To: Cc: Dear team, Until now, I have had only positive responses on issue 1154. This resolution is one of the first that will enable us to build a proper xsd stack based common, small and neat infrastructure. I would like the issue to be proposed for the next ballot. Bran said that the resolution seems to have .important impact. on current UML2 implementations. As a matter of fact, most UML 2 implementation, like the one in Eclipse, flatten the UML metamodel. As the resolution only deals with the very abstract parts of the infrastructure there should be no changes for flattened models. Antoine From: Frank, Karl (Mission Systems) [mailto:Karl.Frank@ngc.com] Sent: Thursday, August 09, 2007 4:22 PM To: Branislav Selic; LONJON Antoine; uml2-rtf@omg.org Cc: bmm-ftf@omg.org; bpdm-ftf@omg.org Subject: RE: Response to issue 1154 -- PLEASE REVIEW This email is to support Antoine's suggestions based on two development experiences: 1. BPDM I was working with the BPDM submission team while Antoine was wrestling with the task of defining a metamodel for BPMN and BPDM and observed how the infrastructure library failed to fulfill its stated purpose of providing a reusable basis for language specification, because of too-tight coupling with UML 2. I think we all recognize that maintenance of the infrastructure has been organizationally merged with maintenance of UML 2.x, and to make it serve its purpose, we need to pay close attention to Antoine's experience, which is our only real review of the Infrastructure per se. 2. Together encompassing 3 OMG languages in one produc I was one of the architects of the Together product a few years ago, and that product supported not just UML 2.0 (about 75% of the mm) but also UML 1.4 and BPMN. We needed to define a higher-level metamodel that could be used to cover all three of these OMG languages. We followed the principle that this metamodel needed to be something distinct from the metamodel specific to any one of the 3, and we found that the infrastructure library could not serve our purposes, it was too geared to UML 2. Both these experiences tend to show that UML Infrastructure needs serious attention if it is to serve its purpose. If we don't give it that attention, we might as well just extract the bit that UML 2 uses and merge it with the superstructure spec. Cordially yours, Karl Frank General Scientist, Mission Systems Northrop-Grumman Corporation GMT-5 (EDT, EST) cell: +1 978 853 3592 -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 09, 2007 9:39 AM To: LONJON Antoine; uml2-rtf@omg.org Cc: bmm-ftf@omg.org; bpdm-ftf@omg.org Subject: Re: Response to issue 1154 -- PLEASE REVIEW Importance: High Thanks, Antoine. I would like to draw the RTF's attention to this proposed resolution by Antoine because it may have a significant impact on current UML 2 implementations. In particlar, I would like to hear from vendors and the impact that they feel this might have on their implementations and customers. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "LONJON Antoine" 08/08/2007 08:39 AM To cc , Subject Response to issue 1154 Dear all, In issue 1154, I have expressed the need to use Core:Abstractions as a thin infrastructure for all non UML based specifications such as BPDM, BMM, OSM, SBVR. The following proposals makes a few change to Core:Abstractions in order to add packaging capabilities than are only available in Constructs. The proposal looks quite long because it includes all rewriting (most of them are copy from Constructs) that are done to Core:Abstractions. For the sake of model interoperability and complementary, it is essential that all specifications share this minimum Core set. Antoine **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** [attachment "Issue 1154 - Resolution.doc" deleted by Branislav Selic/Ottawa/IBM] **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** To: "LONJON Antoine" Cc: bpdm-ftf@omg.org, uml2-rtf@omg.org, jamsden@us.ibm.com Subject: RE: Response to issue 1154 -- PLEASE REVIEW X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Tue, 4 Sep 2007 13:37:14 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 09/04/2007 13:37:17, Serialize complete at 09/04/2007 13:37:17 Antoine, My apologies for not responding sooner to your proposal. I had asked Kenn Hussey, the Eclipse UML 2 open source lead, to provide me with feedback on the impact of your proposal but he left IBM several weeks ago. So, here is my feedback on your proposal (based on a relatively superficial review): (1) One potentially major problem that I see with it is that it couples the Constructs and Abstractions in the Infrastructure. For better or worse, the decision was made during the FTF to decouple these two packages: Constructs was intended to provide the foundation for UML, whereas Abstractions was intended to provide a useful catalogue of general metamodeling patterns for domain-specific modeling languages. Unfortunately, because we did not have resources to maintain both, most of the FTF and RTF maintenance effort was dedicated to Constructs while Abstractions was pretty much abandoned and is now in a suspect state. (Pete wanted to work on it more, but ran out of cycles.) As a result, the Superstructure makes no use of Abstractions. In fact, at one time, there was a proposal to completely remove Abstractions from the Infrastructure. If you examine the two packages, you will notice that they both define similar (but not identical) metamodel structures and classes -- EXCEPT THAT THEY DO SO INDEPENDENTLY OF EACH OTHER. Clearly, this is suboptimal, and is primarily due to expediency and lack of bandwidth. Fixing this now is a major effort. (2) My other concern is one that I expressed earlier in an RTF posting: I am concerned that rearranging things near the root of the metaclass hierarchy will lead to unanticipated side-effects, due to the poorly designed UML metaclass hierarchy. It is true that the package merges used to derive the UML metamodels result in a flattened structure, I am not convinced that the result will be the same for all concrete classes. This may very well be the case, but, other than exhaustive inspection of each and every concrete UML metaclass, I don't see how we can be sure of that. (Had the UML metamodel been designed as a strictly layered hierarchy with well defined interfaces between layers, this task could be simplified; but this is not the case, unfortunately.) One possible solution that comes to mind is that you make your desired change in Abstractions only (leaving Constructs untouched), but this would mean that you would not be defining a UML profile but a UML-like domain-specific language. I am not sure what you guys are doing, but I suspect that this is an issue. Let's look into the possibilities some more. Once again, I apologize for not commenting on this earlier. Regards, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "LONJON Antoine" 09/04/2007 06:34 AM To cc Subject RE: Response to issue 1154 -- PLEASE REVIEW Dear team, Until now, I have had only positive responses on issue 1154. This resolution is one of the first that will enable us to build a proper xsd stack based common, small and neat infrastructure. I would like the issue to be proposed for the next ballot. Bran said that the resolution seems to have .important impact. on current UML2 implementations. As a matter of fact, most UML 2 implementation, like the one in Eclipse, flatten the UML metamodel. As the resolution only deals with the very abstract parts of the infrastructure there should be no changes for flattened models. Antoine From: Frank, Karl (Mission Systems) [mailto:Karl.Frank@ngc.com] Sent: Thursday, August 09, 2007 4:22 PM To: Branislav Selic; LONJON Antoine; uml2-rtf@omg.org Cc: bmm-ftf@omg.org; bpdm-ftf@omg.org Subject: RE: Response to issue 1154 -- PLEASE REVIEW This email is to support Antoine's suggestions based on two development experiences: 1. BPDM I was working with the BPDM submission team while Antoine was wrestling with the task of defining a metamodel for BPMN and BPDM and observed how the infrastructure library failed to fulfill its stated purpose of providing a reusable basis for language specification, because of too-tight coupling with UML 2. I think we all recognize that maintenance of the infrastructure has been organizationally merged with maintenance of UML 2.x, and to make it serve its purpose, we need to pay close attention to Antoine's experience, which is our only real review of the Infrastructure per se. 2. Together encompassing 3 OMG languages in one produc I was one of the architects of the Together product a few years ago, and that product supported not just UML 2.0 (about 75% of the mm) but also UML 1.4 and BPMN. We needed to define a higher-level metamodel that could be used to cover all three of these OMG languages. We followed the principle that this metamodel needed to be something distinct from the metamodel specific to any one of the 3, and we found that the infrastructure library could not serve our purposes, it was too geared to UML 2. Both these experiences tend to show that UML Infrastructure needs serious attention if it is to serve its purpose. If we don't give it that attention, we might as well just extract the bit that UML 2 uses and merge it with the superstructure spec. Cordially yours, Karl Frank General Scientist, Mission Systems Northrop-Grumman Corporation GMT-5 (EDT, EST) cell: +1 978 853 3592 -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 09, 2007 9:39 AM To: LONJON Antoine; uml2-rtf@omg.org Cc: bmm-ftf@omg.org; bpdm-ftf@omg.org Subject: Re: Response to issue 1154 -- PLEASE REVIEW Importance: High Thanks, Antoine. I would like to draw the RTF's attention to this proposed resolution by Antoine because it may have a significant impact on current UML 2 implementations. In particlar, I would like to hear from vendors and the impact that they feel this might have on their implementations and customers. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "LONJON Antoine" 08/08/2007 08:39 AM To cc , Subject Response to issue 1154 Dear all, In issue 1154, I have expressed the need to use Core:Abstractions as a thin infrastructure for all non UML based specifications such as BPDM, BMM, OSM, SBVR. The following proposals makes a few change to Core:Abstractions in order to add packaging capabilities than are only available in Constructs. The proposal looks quite long because it includes all rewriting (most of them are copy from Constructs) that are done to Core:Abstractions. For the sake of model interoperability and complementary, it is essential that all specifications share this minimum Core set. Antoine **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** [attachment "Issue 1154 - Resolution.doc" deleted by Branislav Selic/Ottawa/IBM] **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** Subject: RE: Response to issue 1154 -- PLEASE REVIEW Date: Wed, 5 Sep 2007 09:26:18 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Response to issue 1154 -- PLEASE REVIEW Thread-Index: AcfvGkQ8C44kWF0NTrOEHr3oj/HB7gAByODA From: "LONJON Antoine" To: "Branislav Selic" Cc: , , Bran, Ø (1) One potentially major problem that I see with it is that it couples the Constructs and Abstractions in the Infrastructure. For better or worse, the decision was made during the FTF to decouple these two packages: Constructs was intended to provide the foundation for UML, whereas Abstractions was intended to provide a useful catalogue of general metamodeling patterns for domain-specific modeling languages. Unfortunately, because we did not have resources to maintain both, most of the FTF and RTF maintenance effort was dedicated to Constructs while Abstractions was pretty much abandoned and is now in a suspect state. (Pete wanted to work on it more, but ran out of cycles.) As a result, the Superstructure makes no use of Abstractions. In fact, at one time, there was a proposal to completely remove Abstractions from the Infrastructure. The proposal is all about solving this problem. Contracts and Abstractions are maintained as separated packages. Abstractions focus on the minimum elements share by all MOF specifications. Constructs adds all elements required for Object Oriented models such as UML. If you examine the two packages, you will notice that they both define similar (but not identical) metamodel structures and classes -- EXCEPT THAT THEY DO SO INDEPENDENTLY OF EACH OTHER. Clearly, this is suboptimal, and is primarily due to expediency and lack of bandwidth. Fixing this now is a major effort. The proposal is just an initial step, but it is enough to help building a proper architecture, especially for building a common XSD stack which is currently missing to the OMG. One of its design principle is to reduce the use of .package merge.. Most package merge were used because Abstractions and Construct were designed .INDEPENDENTLY. as you said. Package Merge creates an illusion of commonalities between the two packages. Wherever simple sub-typing could be used, the proposal uses it. It keeps package merge where only where it was really necessary. The package merge topic is one big part of the proposal. Again, because of the flattened approach of UML in most tools and because Abstractions was almost never used, there should not be major (if any) disruption. The other major part of the proposal concerns the circular definition of Package and Namespace. This is, according to me, the only place were some side-effects could occur. As it covers a very limited scope, it should be easy to figure out the potential issues for modeling tools. My review of the last EMF implementation of UML is that it follows the proper usage of packageableElement and doesn.t mix it with namespace. (2) My other concern is one that I expressed earlier in an RTF posting: I am concerned that rearranging things near the root of the metaclass hierarchy will lead to unanticipated side-effects, due to the poorly designed UML metaclass hierarchy. It is true that the package merges used to derive the UML metamodels result in a flattened structure, I am not convinced that the result will be the same for all concrete classes. This may very well be the case, but, other than exhaustive inspection of each and every concrete UML metaclass, I don't see how we can be sure of that. (Had the UML metamodel been designed as a strictly layered hierarchy with well defined interfaces between layers, this task could be simplified; but this is not the case, unfortunately.) As I said above, most of the proposed reorganization only concern Abstractions, which was not used by any modeling tools. The only real change is on Package and Namespace. One possible solution that comes to mind is that you make your desired change in Abstractions only (leaving Constructs untouched), but this would mean that you would not be defining a UML profile but a UML-like domain-specific language. I am not sure what you guys are doing, but I suspect that this is an issue. One of the goal of the proposal is to be able to better connect the various specifications. For instance, simple interaction in BPDM (a kind of message) carries out resources which are specified by the abstract class .Type.. Some BPDM models may wish to use uml:Class or uml:Datatype as the type of simple interactions. This means that uml:Class and uml:Datatype have abstractions:Type is their class hierarchy. Let's look into the possibilities some more. Once again, I apologize for not commenting on this earlier. Regards, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "LONJON Antoine" 09/04/2007 06:34 AM To cc Subject RE: Response to issue 1154 -- PLEASE REVIEW Dear team, Until now, I have had only positive responses on issue 1154. This resolution is one of the first that will enable us to build a proper xsd stack based common, small and neat infrastructure. I would like the issue to be proposed for the next ballot. Bran said that the resolution seems to have .important impact. on current UML2 implementations. As a matter of fact, most UML 2 implementation, like the one in Eclipse, flatten the UML metamodel. As the resolution only deals with the very abstract parts of the infrastructure there should be no changes for flattened models. Antoine From: Frank, Karl (Mission Systems) [mailto:Karl.Frank@ngc.com] Sent: Thursday, August 09, 2007 4:22 PM To: Branislav Selic; LONJON Antoine; uml2-rtf@omg.org Cc: bmm-ftf@omg.org; bpdm-ftf@omg.org Subject: RE: Response to issue 1154 -- PLEASE REVIEW This email is to support Antoine's suggestions based on two development experiences: 1. BPDM I was working with the BPDM submission team while Antoine was wrestling with the task of defining a metamodel for BPMN and BPDM and observed how the infrastructure library failed to fulfill its stated purpose of providing a reusable basis for language specification, because of too-tight coupling with UML 2. I think we all recognize that maintenance of the infrastructure has been organizationally merged with maintenance of UML 2.x, and to make it serve its purpose, we need to pay close attention to Antoine's experience, which is our only real review of the Infrastructure per se. 2. Together encompassing 3 OMG languages in one produc I was one of the architects of the Together product a few years ago, and that product supported not just UML 2.0 (about 75% of the mm) but also UML 1.4 and BPMN. We needed to define a higher-level metamodel that could be used to cover all three of these OMG languages. We followed the principle that this metamodel needed to be something distinct from the metamodel specific to any one of the 3, and we found that the infrastructure library could not serve our purposes, it was too geared to UML 2. Both these experiences tend to show that UML Infrastructure needs serious attention if it is to serve its purpose. If we don't give it that attention, we might as well just extract the bit that UML 2 uses and merge it with the superstructure spec. Cordially yours, Karl Frank General Scientist, Mission Systems Northrop-Grumman Corporation GMT-5 (EDT, EST) cell: +1 978 853 3592 -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 09, 2007 9:39 AM To: LONJON Antoine; uml2-rtf@omg.org Cc: bmm-ftf@omg.org; bpdm-ftf@omg.org Subject: Re: Response to issue 1154 -- PLEASE REVIEW Importance: High Thanks, Antoine. I would like to draw the RTF's attention to this proposed resolution by Antoine because it may have a significant impact on current UML 2 implementations. In particlar, I would like to hear from vendors and the impact that they feel this might have on their implementations and customers. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "LONJON Antoine" 08/08/2007 08:39 AM To cc , Subject Response to issue 1154 Dear all, In issue 1154, I have expressed the need to use Core:Abstractions as a thin infrastructure for all non UML based specifications such as BPDM, BMM, OSM, SBVR. The following proposals makes a few change to Core:Abstractions in order to add packaging capabilities than are only available in Constructs. The proposal looks quite long because it includes all rewriting (most of them are copy from Constructs) that are done to Core:Abstractions. For the sake of model interoperability and complementary, it is essential that all specifications share this minimum Core set. Antoine **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** [attachment "Issue 1154 - Resolution.doc" deleted by Branislav Selic/Ottawa/IBM] **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** To: "LONJON Antoine" Cc: bpdm-ftf@omg.org, jamsden@us.ibm.com, uml2-rtf@omg.org Subject: RE: Response to issue 1154 -- PLEASE REVIEW X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Wed, 5 Sep 2007 13:26:34 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 09/05/2007 13:26:36, Serialize complete at 09/05/2007 13:26:36 Thanks, Antoine. Replies in red below. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "LONJON Antoine" 09/05/2007 03:26 AM To Branislav Selic/Ottawa/IBM@IBMCA cc , , Subject RE: Response to issue 1154 -- PLEASE REVIEW Bran, Ø (1) One potentially major problem that I see with it is that it couples the Constructs and Abstractions in the Infrastructure. For better or worse, the decision was made during the FTF to decouple these two packages: Constructs was intended to provide the foundation for UML, whereas Abstractions was intended to provide a useful catalogue of general metamodeling patterns for domain-specific modeling languages. Unfortunately, because we did not have resources to maintain both, most of the FTF and RTF maintenance effort was dedicated to Constructs while Abstractions was pretty much abandoned and is now in a suspect state. (Pete wanted to work on it more, but ran out of cycles.) As a result, the Superstructure makes no use of Abstractions. In fact, at one time, there was a proposal to completely remove Abstractions from the Infrastructure. The proposal is all about solving this problem. Contracts and Abstractions are maintained as separated packages. Abstractions focus on the minimum elements share by all MOF specifications. Constructs adds all elements required for Object Oriented models such as UML. [bvs] I understand the motivation and agree that the problem needs to be resolved eventually, but this is really a much bigger issue than was originally raised. I do not believe that we can or should try to fix this architectural issue in this RTF. Note that it also affects the MOF. If you examine the two packages, you will notice that they both define similar (but not identical) metamodel structures and classes -- EXCEPT THAT THEY DO SO INDEPENDENTLY OF EACH OTHER. Clearly, this is suboptimal, and is primarily due to expediency and lack of bandwidth. Fixing this now is a major effort. The proposal is just an initial step, but it is enough to help building a proper architecture, especially for building a common XSD stack which is currently missing to the OMG. One of its design principle is to reduce the use of .package merge.. Most package merge were used because Abstractions and Construct were designed .INDEPENDENTLY. as you said. Package Merge creates an illusion of commonalities between the two packages. [bvs] Actually, package merge was introduced to address the need to define languages such as UML in a modular fashion (e.g., to support different compliance levels). Wherever simple sub-typing could be used, the proposal uses it. It keeps package merge where only where it was really necessary. The package merge topic is one big part of the proposal. Again, because of the flattened approach of UML in most tools and because Abstractions was almost never used, there should not be major (if any) disruption. [bvs] But, you are changing the root of the Kernel, so I am greatly concerned that we will get unexpected side effects as a result of this change. I would prefer to see some positive proof that this will not happen. The other major part of the proposal concerns the circular definition of Package and Namespace. This is, according to me, the only place were some side-effects could occur. As it covers a very limited scope, it should be easy to figure out the potential issues for modeling tools. [bvs] If this is so, let's do it. That is, can you provide proof that it will NOT have any impact on existing models and tools? My review of the last EMF implementation of UML is that it follows the proper usage of packageableElement and doesn.t mix it with namespace. (2) My other concern is one that I expressed earlier in an RTF posting: I am concerned that rearranging things near the root of the metaclass hierarchy will lead to unanticipated side-effects, due to the poorly designed UML metaclass hierarchy. It is true that the package merges used to derive the UML metamodels result in a flattened structure, I am not convinced that the result will be the same for all concrete classes. This may very well be the case, but, other than exhaustive inspection of each and every concrete UML metaclass, I don't see how we can be sure of that. (Had the UML metamodel been designed as a strictly layered hierarchy with well defined interfaces between layers, this task could be simplified; but this is not the case, unfortunately.) As I said above, most of the proposed reorganization only concern Abstractions, which was not used by any modeling tools. The only real change is on Package and Namespace. [bvs] Yes, and this is precisely the one that I am worried about. However, if it can be demonstrated that it has no adverse side effects, I would have no objection to this resolution. One possible solution that comes to mind is that you make your desired change in Abstractions only (leaving Constructs untouched), but this would mean that you would not be defining a UML profile but a UML-like domain-specific language. I am not sure what you guys are doing, but I suspect that this is an issue. One of the goal of the proposal is to be able to better connect the various specifications. For instance, simple interaction in BPDM (a kind of message) carries out resources which are specified by the abstract class .Type.. Some BPDM models may wish to use uml:Class or uml:Datatype as the type of simple interactions. This means that uml:Class and uml:Datatype have abstractions:Type is their class hierarchy. Let's look into the possibilities some more. Once again, I apologize for not commenting on this earlier. Regards, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "LONJON Antoine" 09/04/2007 06:34 AM To cc Subject RE: Response to issue 1154 -- PLEASE REVIEW Dear team, Until now, I have had only positive responses on issue 1154. This resolution is one of the first that will enable us to build a proper xsd stack based common, small and neat infrastructure. I would like the issue to be proposed for the next ballot. Bran said that the resolution seems to have .important impact. on current UML2 implementations. As a matter of fact, most UML 2 implementation, like the one in Eclipse, flatten the UML metamodel. As the resolution only deals with the very abstract parts of the infrastructure there should be no changes for flattened models. Antoine From: Frank, Karl (Mission Systems) [mailto:Karl.Frank@ngc.com] Sent: Thursday, August 09, 2007 4:22 PM To: Branislav Selic; LONJON Antoine; uml2-rtf@omg.org Cc: bmm-ftf@omg.org; bpdm-ftf@omg.org Subject: RE: Response to issue 1154 -- PLEASE REVIEW This email is to support Antoine's suggestions based on two development experiences: 1. BPDM I was working with the BPDM submission team while Antoine was wrestling with the task of defining a metamodel for BPMN and BPDM and observed how the infrastructure library failed to fulfill its stated purpose of providing a reusable basis for language specification, because of too-tight coupling with UML 2. I think we all recognize that maintenance of the infrastructure has been organizationally merged with maintenance of UML 2.x, and to make it serve its purpose, we need to pay close attention to Antoine's experience, which is our only real review of the Infrastructure per se. 2. Together encompassing 3 OMG languages in one produc I was one of the architects of the Together product a few years ago, and that product supported not just UML 2.0 (about 75% of the mm) but also UML 1.4 and BPMN. We needed to define a higher-level metamodel that could be used to cover all three of these OMG languages. We followed the principle that this metamodel needed to be something distinct from the metamodel specific to any one of the 3, and we found that the infrastructure library could not serve our purposes, it was too geared to UML 2. Both these experiences tend to show that UML Infrastructure needs serious attention if it is to serve its purpose. If we don't give it that attention, we might as well just extract the bit that UML 2 uses and merge it with the superstructure spec. Cordially yours, Karl Frank General Scientist, Mission Systems Northrop-Grumman Corporation GMT-5 (EDT, EST) cell: +1 978 853 3592 -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 09, 2007 9:39 AM To: LONJON Antoine; uml2-rtf@omg.org Cc: bmm-ftf@omg.org; bpdm-ftf@omg.org Subject: Re: Response to issue 1154 -- PLEASE REVIEW Importance: High Thanks, Antoine. I would like to draw the RTF's attention to this proposed resolution by Antoine because it may have a significant impact on current UML 2 implementations. In particlar, I would like to hear from vendors and the impact that they feel this might have on their implementations and customers. Cheers, Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "LONJON Antoine" 08/08/2007 08:39 AM To cc , Subject Response to issue 1154 Dear all, In issue 1154, I have expressed the need to use Core:Abstractions as a thin infrastructure for all non UML based specifications such as BPDM, BMM, OSM, SBVR. The following proposals makes a few change to Core:Abstractions in order to add packaging capabilities than are only available in Constructs. The proposal looks quite long because it includes all rewriting (most of them are copy from Constructs) that are done to Core:Abstractions. For the sake of model interoperability and complementary, it is essential that all specifications share this minimum Core set. Antoine **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** [attachment "Issue 1154 - Resolution.doc" deleted by Branislav Selic/Ottawa/IBM] **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ******************************************************************************