Issue 5865: Different element should be used to represent MOF imports (uml-edoc-ftf) Source: Oracle (Mr. Martin Matula, nobody) Nature: Uncategorized Issue Severity: Summary: MOF Import can be represented by UML ElementImport. Again, I was not able to use ElementImport in UML tools I know of. Different element should be used to represent MOF imports. Resolution: Revised Text: Actions taken: February 13, 2003: received issue Discussion: End of Annotations:===== Date: Thu, 13 Feb 2003 10:30:21 +0100 From: Martin Matula Subject: Issues (UML Profile for MOF) To: uml-edoc-ftf@omg.org X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 Hi, I am sorry to send this a month after the comment deadline, but as I understand from the Keith's e-mail below, it is OK to raise further issues before April 15th. Here are some issues related to UML Profile for MOF - I am raising them as I think that as is the profile is quite useless (I was trying to implement it and then decided to go with my own modification - see http://mdr.netbeans.org/uml2mof/profile.html). Since all of the issues below are resolved in my modification of the profile, I am ready to provide the resolutions quite quickly. Anyway, if you think that these come too late I don't mind - I just thought I should let you know what my experience from trying to apply this profile was. Here are the issues MOF Import can be represented by UML ElementImport. Again, I was not able to use ElementImport in UML tools I know of. Different element should be used to represent MOF imports. Subject: RE: issues 5865 - 5869 -- UML Profile for EDOC FTF issues Date: Wed, 26 Feb 2003 10:20:58 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issues 5865 - 5869 -- UML Profile for EDOC FTF issues Thread-Index: AcLc//BHBb7LTrT/QyiFvFeLgRZX2AALVMkA From: "Pete Rivett" To: X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id h1QAJVF02747 Martin, These issues seem a bit inconsistent: in many cases you argue for NOT using UML capabilities on the basis that 'many tools do not support them', but then in issue #5867 you argue for using UML parameter multiplicity which is also not supported by all tools (Rose comes to mind). As a separate point, I think if we stick to UML capabilities that most UML tools support then that will tend to scupper most of the UML Profile for the rest of EDOC. I guess we should take a policy decision on this: personally I think trying to determine what UML capabilities we can reasonably expect tools to have could soak up a lot of time and effort to be fair. And it defeats the point of having a UML standard. In general for each UML tool it should be possible to state a way of achieving/working round those UML capabilities it does not directly support - as Martin suggests in the text of these issues. This is a question of UML support not of EDOC support. These workrounds can then be used for the tool to support EDOC in the same way as they're used for the tool to support UML. Another approach that has been used is to have separate tool-dependent profiles: for example Unisys produced a 'Rose Profile for MOF' - a variant of the official UML Profile for MOF that described how to use Rose in a standard way to get round the UML capabilities needed that it does not provide. Pete Pete Rivett (pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Juergen Boldt [mailto:juergen@omg.org] > Sent: 25 February 2003 18:52 > To: issues@omg.org; uml-edoc-ftf@omg.org > Subject: issues 5865 - 5869 -- UML Profile for EDOC FTF issues > > > All issues submitted by Martin Matula > > > This is issue # 5865 > > Different element should be used to represent MOF imports > > MOF Import can be represented by UML ElementImport. Again, I > was not able to use ElementImport in UML tools I know of. > Different element should be used to represent MOF imports. > > ================ > > This is issue # 5866 > > Exception and thus also the raisedSignal reference not supported > > Raised exceptions are supposed to be linked via raisedSignal reference > to operation. However, as I already wrote in one of the > previous issues, Exception and thus also the raisedSignal > reference is not supported in Class diagrams by most of the > tools. Different way of modeling raised exceptions would make > it usable > > ================ > > This is issue # 5867 > > Tag for multiplicity > > Tag for multiplicity is introduced for Parameters, however in > UML 1.4 multiplicity on parameters is natively supported. > > ================= > > This is issue # 5868 > > UML Models are not supported by some existing UML tools > > While the profile allows MOF Packages to be represented by > UML Models only, UML Models are not supported by some > existing UML tools - representation using UML Package would > be better. Also org.omg.uml2mof.clusteredImport tag is > introduced for clustered imports declarations. This can be > solved more nicely without introducing a new tag (e.g. by a > dependency stereotyped <>) > > ================ > > This is issue # 5869 > > package generalization > > Package subtyping is handled by a standard > generalization.parent reference however many UML tools do not > support package generalization - it should be modeled > differently (e.g. using a stereotyped dependency) > > > > ================================= > J|rgen Boldt > Director, Member Services > > Object Management Group > 250 First Avenue, Suite 100 > Needham, MA 02494 > > Tel. +1 781 444 0404 ext. 132 > Fax: +1 781 444 0320 > email: juergen@omg.org > www www.omg.org > > ================================ > > The information contained in this email and any attached files is confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company.