Issue 7761: Allow Models to be referenced from Assets and avoid duplicating UML (ras-ftf) Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com) Nature: Uncategorized Issue Severity: Summary: It's not at all clear how to use RAS to reference UML (or other) models which might represent the design of a component, or might be reusable assets in their own right - despite the fact that the Model may be in the same repository as the RAS Asset definition! The description of Artifact (in Section 2.4.10.1 of the RFC) clearly implies that an Artifact must be (or refer to) a file: while it would be possible to export a Model as a XMI file and reference it, this dramatically reduces the possibility of proper management, editing and impact analysis of the modeling elements, and should only be required for physical interchange purposes. In fact requiring models to be instantiated in XMI files ironically works against the reuse of the model elements (e.g. common classes reused in the design of multiple components). The RAS Profile mechanism seems to require the construction of new RAS-specific metamodels and does not seem readily to allow the re-use of existing metamodels, models and tools such as UML. For example, a more sensible approach for support of John Cheesman's Component book would be to use a UML Profile (as indeed he does in the book!) and allow the top level package to be linked to the Asset. Similarly the UML Diagram Interchange standard already has a metamodel for Diagrams (linked to model elements) so why create another representation here? Proposed resolution: Allow artifacts to reference arbitrary model elements (this can be achieved through an association to Reflective::Object which is the implicit superclass of every class in a MOF 2 metamodel). Allow a RAS Profile to refer to a Package (representing a metamodel or UML Profile) rather than having to create its own metamodel. Resolution: Revised Text: The asset's type, as identified through the Profile class, may be conceptually any thing. This is expressed in the association of Profile to MOF::Element. Further, the Artifact reference attribute is replaced with a primitive Reference class. The Reference has an association with MOF::Element, thereby allowing the Artifact to reference any thing, including a UML model. The Reference may be of any kind, as expressed in the association with ReferenceKind. Resolution: The following section and text should be added. 7.4.9 MOF Classes MOF::Element {isAbstract = true} MOF::Element is merged with MOF:Reflection allowing any element to be referenced from a profile. MOF::Class {isAbstract = true} MOF::Class represents the required elements for the profile MOF::Property {isAbstract = true} MOF::Property represents the required attributes for the profile MOF::Constraint {isAbstract = true} MOF::Constraint represents the textual and OCL constraints for the profile The following model and text changes should be appended to the section below. 7.4.8 Profile {isAbstract = false} (update the current section with the text and image below) An asset is defined by one profile; a profile describes the asset's type. The profile can have different versions and should declare its lineage or ancestry from other profiles. A profile can reference other model elements that can be used to describe the profile, for example UML packages or classes. References element type = Element [0..1] - The optionally referenced model element used to describe the profile. classificationSchema type = ClassificationSchema [0..*] - This refers to the classification schema for the profile. dependencyKind type = DependencyKind [0..*] - The optionally referenced kinds of dependencies relevant for this profile. The following section, text, and image should be added. 7.4.10.6 Reference {isAbstract = false} A reference to an external element. This kind either can be loosely coupled through the value attribute, such as a URI or reference an existing model element, that further describes the artifact. Attributes value type = String [1...1] - The value which can be used to resolve an external reference, typically a URI that is resolved depending upon the reference kind. References description type = Description [0..1] - An optional description for the reference. referenceKind type = ReferenceKind [1..1] - A mandatory kind for the reference that can be used to interpret the value or the element reference. element type = Element [0..1] - The optionally referenced model element used to further describe the artifact. The following section, text, and image should be added. 7.4.10.7 ReferenceKind {isAbstract = false} The reference kind associated with references that are used to determine how the implementation should interpret the reference. Some suggested examples include 'Internal Reference' for associated elements and 'External Reference' for URIs held against the value attribute of the reference. Attributes name type = String [1..1] - The name of the reference kind. References description type = Description [0..1] - The optional description of the reference kind. Editorial Note: see issue 8521 for other items on this class. Actions taken: September 20, 2004: received issue August 1, 2005: closed issue Discussion: Proposed resolution: Allow artifacts to reference arbitrary model elements (this can be achieved through an association to Reflective::Object which is the implicit superclass of every class in a MOF 2 metamodel). Allow a RAS Profile to refer to a Package (representing a metamodel or UML Profile) rather than having to create its own metamodel. End of Annotations:===== llow Models to be referenced from Assets and avoid duplicating UML It's not at all clear how to use RAS to reference UML (or other) models which might represent the design of a component, or might be reusable assets in their own right - despite the fact that the Model may be in the same repository as the RAS Asset definition! The description of Artifact (in Section 2.4.10.1 of the RFC) clearly implies that an Artifact must be (or refer to) a file: while it would be possible to export a Model as a XMI file and reference it, this dramatically reduces the possibility of proper management, editing and impact analysis of the modeling elements, and should only be required for physical interchange purposes. In fact requiring models to be instantiated in XMI files ironically works against the reuse of the model elements (e.g. common classes reused in the design of multiple components). The RAS Profile mechanism seems to require the construction of new RAS-specific metamodels and does not seem readily to allow the re-use of existing metamodels, models and tools such as UML. For example, a more sensible approach for support of John Cheesman's Component book would be to use a UML Profile (as indeed he does in the book!) and allow the top level package to be linked to the Asset. Similarly the UML Diagram Interchange standard already has a metamodel for Diagrams (linked to model elements) so why create another representation here? Proposed resolution: Allow artifacts to reference arbitrary model elements (this can be achieved through an association to Reflective::Object which is the implicit superclass of every class in a MOF 2 metamodel). Allow a RAS Profile to refer to a Package (representing a metamodel or Subject: Adaptive RAS FTF Issues Date: Mon, 28 Feb 2005 11:45:14 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Adaptive RAS FTF Issues Thread-Index: AcUUZhEHnc3QCGOjSl2gE5pXdAMRfAJPbB3A From: "Nick Dowler" To: X-Virus-Scanned: by amavisd-new at sentraliant.com All, Please find attached the proposed models to address issues 7759 and 7761. For issue 7766, we suggest that the xmi.uuid is used for clarity of globally unique IDs. Kind regards, Nick. UML Profile) rather than having to create its own metamodel.