Issue 13838: AMSM FTF2 report XMI file (amsm-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Uncategorized Issue Severity: Summary: AMSM FTF2 report XMI file http://doc.omg.org/dtc/09-02-10 [PJR] This is a UML 1.4 XMI 1.1 file, created by a Japanese tool called Jude. It has some structural problems e.g. AssociationEnds owned by the Package not the Association. Resolution: When resolving other issues (13316, 14091) we decided to move the entire AMSM UML model to a new UML tool (SparxSystems Enterprise Architect) capable of generating better XMI than Jude. This substantial effort has now been finalized and new XMI (version 2.1) has been generated as part of the transfer. The file has been tested against different UML tools, but the vote on that issue has not yet taken place. The new EA UML model file and the XMI file are attached to the FTF document package as non-normative documents (see inventory). It is proposed to vote on this issue as soon as possible in the next RTF period. Disposition: Deferred Revised Text: Actions taken: March 26, 2009: received issue Discussion: End of Annotations:===== ubject: Issue with AMSM Date: Thu, 26 Mar 2009 13:10:48 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue with AMSM Thread-Index: AcmuTvRySh5Er1sjSgmowQ7EgJ5ApQ== From: "Pete Rivett" To: Cc: "Andrew Watson" AMSM FTF2 report XMI file http://doc.omg.org/dtc/09-02-10 [PJR] This is a UML 1.4 XMI 1.1 file, created by a Japanese tool called Jude. It has some structural problems e.g. AssociationEnds owned by the Package not the Association. Pete X-WSS-ID: 0KN4X1V-05-0UE-02 X-M-MSG: From: Burkhart Roger M To: Eldad Palachi , "sysml-rtf@omg.org" Date: Tue, 21 Jul 2009 08:49:12 -0500 Subject: RE: Regarding issue 12219: suggest need Quantity stereotype and definition Thread-Topic: Regarding issue 12219: suggest need Quantity stereotype and definition Thread-Index: AcoKBAwhVMHErFr1QU6nXcD3fkujzgAAVWFQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n6LDkRVi004888 Eldad-- > 1. Why did you add attributes for symbol, description, etc. to Unit - is > this really necessary? It's a minimal step to begin providing more documentation about units and quantity kinds defined using the stereotypes, and to provide loose forms of coupling to separate, more comprehensive definitions and documentation that could be captured using the separate model library or by other means. > 2. Why did you add Rational to the model library of predefined value types? > I don't object to Integer, but Rational is something that tools might be > expected to present as X/Y? Is this really necessary? Can't we just remain > with Real? I agree that Rational is needed only for very specialized purposes, and could be left out of the normative predefined types defined in the blocks model library. We do need it to make sure we can define exact unit conversions in the QUDV conceptual model, but it could be moved into the conceptual model where it's specifically needed, and left out of the model library in Chapter 8. I'm willing to make that change if nobody objects. > 3. I don't understand why in the proposed annex you show blocks and not > stereotypes? Shouldn't these be either meta-classes (if this is conceptual > model) or stereotypes if you are describing a profile? For example the Unit > stereotype is defined in Chapter 8 and here we have a Unit block - are > these concepts the same or different? A conceptual model can be expressed entirely using blocks (in SysML) or classes (in UML). Metaclasses are for defining new modeling languages, not to apply an already defined language to defining concepts and their relationships. The Unit stereotype in Chapter 8 is necessary because SysML already makes it part of its extensions to UML language elements, both in the metamodel and in the diagram elements. The number of concepts and their relationships make it much more straightforward to define them all in an ordinary user model, and to provide optional loose coupling to these from the existing stereotypes. For the sake of compatibility with SysML 1.1, we agreed we needed to keep the existing stereotypes and their use by the existing ValueType stereotype (other than adding the extra, optional documentation attributes, and the renaming of Dimension to QuantityKind). This approach was decided on in multiple working sessions at the Costa Rica which included people from the MARTE and Modelica working groups. It ended up being an acceptable compromise between keeping compatibility and providing an optional path to much more comprehensive definition of systems of units and quantities as supported by the conceptual model. Since it's non-normative, if anyone sees a need to define a stereotype- based version of the conceptual model, they're free to do so. As noted with the conceptual model, we also see a need to publish a pure UML class-based version of this model, even though that's not included in the SysML document. > 4. I think there is a need for an example to show how one uses the proposed > model library effectively - I was able to understand that this proposal > provides a way to have unit conversions - but I am not sure how exactly I > am supposed to use it. I agree that examples and sample reference libraries of units and quantity kinds are needed to apply the model and show multiple ways of using it. We have developed some examples of units from the SI system expressed using the model, and a mass-spring-damper example, and expect to publish versions of these at the link which is included in Annex C.5. For the SysML specification itself, however, that would be more example material than would easily fits into the document (the new Annex C.5 already runs 15 pages). I agree, however, that a some basic examples in two or three pages would be worth including. --Roger Subject: RE: Issue 13838 and UML model Date: Wed, 22 Jul 2009 12:27:12 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 13838 and UML model Thread-Index: AcoK1wYY9wEjOG9QQH2+9MpdQFvXzQAEjQoQ From: "Townsen, Ronald W." To: "Jacek Skowronek" , X-OriginalArrivalTime: 22 Jul 2009 16:27:19.0585 (UTC) FILETIME=[48A41110:01CA0AE9] 2.1 loaded fine in Rhapsody Ronald W Townsen Sr. Lead Engineer General Dynamics Advanced Information Systems Office: 703-885-3621 Blackberry: 703-407-2030 From: Jacek Skowronek [mailto:jacek.skowronek@nl.thalesgroup.com] Sent: Wednesday, July 22, 2009 10:14 AM To: amsm-rtf@omg.org Subject: Issue 13838 and UML model Hi all, As the new AMSM RTF chair, I started by having a look at the issues on the table. Of the 7 issues there 6 are coming from my company, so I will be proposing resolutions for those shortly. However the last issue (13838) is a bigger one, and concerns the XMI file of the AMSM model. Apparently it is broken and therefore we should fix it. As you remember our UML model was done in Jude (by Hugues), and XMI was generated from that. I have looked at Jude, and have decided we should try to move the UML model to a more popular UML tool, with better XMI generation. In fact, I have already done that, and imported our AMSM XMI into Enterprise Architect. As raised by the issue, the import was far from perfect, as many associations disappeared, and (more importantly), the diagrams have been gone. I have therefore (laboriously) recreated all the diagrams in EA, attempting to make them identical to the ones in the Beta2 spec. I think I fairly succeeded in that, as we have now 20+ diagrams in the EA model which can be used to replace the old ones. To test if the new model generates proper XMI, I have used EA to generate a new AMSM XMI file, and would like to ask you guys to test the import of that XMI into any tool you may have. This should help us get a proper XMI, which we can then post to the OMG server. There are three files attached to the message: amsm_xmi_1_2.xmi, which is XMI 1.2 version of the model. There is also a DTD file called UML_EA.DTD which may be needed for import of that XMI (depends on the tool). amsm_xmi_2_1.xmi, which is XMI 2.1 version of the model. For that one you should not need a DTD. Could some of you test (import) those files against any UML tools you may be using (RSA, Rhapsody, etc) and report any issues back to the amsm-rtf mailing list? After the XMI is checked against a couple of tools, I will submit the new XMI to OMG before the next meeting as a resolution of the issue 13838. I have also discovered a missing diagram in the Beta 2 spec and will be raising this as an issue separately. Cheers and hope you can help, Jacek Unclassified e-mail ------------------------------------------------------------------------------------------------------------ Disclaimer: If you are not the intended recipient of this email, please notify the sender and delete it. Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden. Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s). Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578. ------------------------------------------------------------------------------------------------------------