Issue 9962: Subclasses of InstanceSpecification (uml2-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: Now, when link is not Link and is not Relationship, tool >> developers must use >> a lot of hacks for handling this "special kind of instance" >> as path, to >> create special algorithms for "relatedElements" calculation, >> to prevent >> type changes to regular classifier and for many other situations. >> Why Link metaclass was removed? Why all subclasses of >> Instance were removed? >I don't know. I personally would like to see an explicit Link class in >the Instances metamodel - see the MOF Core specification (abstract >semantics chapter - which is purely descriptive and does not add these >Instance extensions to MOF or UML) for what I have in mind. I would >support adding this all into UML since it would be a non-disruptive >(forward compatible) extension. >> Node instance and Component instance "different handling" and >> notation >> creates a lot problems also, because it is not possible to >> recognize them in >> the model (classifier could be unspecified). Resolution: Revised Text: Actions taken: July 25, 2006: received issue Discussion: End of Annotations:===== ssue #2 - Subclasses of InstanceSpecification >> Now, when link is not Link and is not Relationship, tool >> developers must use >> a lot of hacks for handling this "special kind of instance" >> as path, to >> create special algorithms for "relatedElements" calculation, >> to prevent >> type changes to regular classifier and for many other situations. >> Why Link metaclass was removed? Why all subclasses of >> Instance were removed? >I don't know. I personally would like to see an explicit Link class in >the Instances metamodel - see the MOF Core specification (abstract >semantics chapter - which is purely descriptive and does not add these >Instance extensions to MOF or UML) for what I have in mind. I would >support adding this all into UML since it would be a non-disruptive >(forward compatible) extension. >> Node instance and Component instance "different handling" and >> notation >> creates a lot problems also, because it is not possible to >> recognize them in >> the model (classifier could be unspecified). >Have you raised an issue on this? >Pete Nerijus ----- Original Message ----- From: Juergen Boldt To: conrad.bock@nist.gov ; 'Nerijus Jankevicius' ; 'Ed Seidewitz' Cc: uml2-rtf@omg.org Sent: Tuesday, July 25, 2006 4:42 PM Subject: RE: link ends Folks, looks like there is an issue. Anybody willing to formulate one? -Juergen At 09:28 AM 7/25/2006, Conrad Bock wrote: P.S. One more fix would be useful: a way to tell which properties owned by an association class are not end object properties and not properties navigating from link to end objects either. > One fix is a normative model library with a association class with > normative names for the properties that navigate from link to end > objects. Or a stereotype to identify such properties. Conrad Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org X-YMail-OSG: Vrd1BvQVM1mWTxJemCy9_JThvddTsID2T4AnMrgtFvQEy6SRuHTLXSiQBaF5_czvEg-- Reply-To: From: "Thomas Weigert" To: "'Nerijus Jankevicius'" , "'Tim Weilkiens'" , Cc: "'Branislav Selic'" , "'Pete Rivett'" Subject: RE: updated resolutions for UML 2.2 Date: Fri, 31 Aug 2007 21:20:04 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acfr32xEUYI+MSCISnigJyjbz2KUlwAXpAug Regarding issue 8077, 9961, 9962 The proposed resolution violates the original strategy of the instance metamodel which explicitly and purposefully removed "Link" as a metaclass together with the convolutions that surrounded it. We should not reintroduce these concepts we have worked hard to get rid of. Issues 8077 and issue 9961 do not appear correct. Cheers, Th. > -----Original Message----- > From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > Sent: Friday, August 31, 2007 9:42 AM > To: Tim Weilkiens; uml2-rtf@omg.org > Cc: Branislav Selic; Pete Rivett > Subject: Re: updated resolutions for UML 2.2 To: "Nerijus Jankevicius" Cc: "Pete Rivett" , uml2-rtf@omg.org Subject: Re: updated resolutions for UML 2.2 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Branislav Selic Date: Tue, 4 Sep 2007 08:26:44 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 7.0.2HF446 | March 16, 2007) at 09/04/2007 08:26:44, Serialize complete at 09/04/2007 08:26:44 Thank you very much, Nerijus, for taking the initiative to propose resolutions to these issues. I've already commented a bit on some of the proposed resolutions, but here is my complete list of comments to each of your resolutions. I believe that we will need more discussions on these issues in the next few weeks. ====================================================================== Issue 11240: Indeed there seems to be redundancy between TemplateParameter::default and ClassifierTemplateParameter::defaultClassifier, but there are numerous examples of this in the spec. It allows polymorphism, so that software dealing with TemplateParameters in general can ignore which type of specialization is in question. Redefinition would prevent that capability. What is the motivation behind this issue and resolution? Is it implementation optimization, metamodel consistency, or something else? What effect will this have on users and existing models, if any? Issue 11244: Same comment as 11240 Issue 11243: Seems OK, except that the text needs to be fixed a bit to ensure correct English usage; here is a suggestion (italics are words that I changed from your original): . constrainingClassifier : Classifier [0..*] The classifiers that constrain the argument that can be used for the parameter. If the allowSubstitutable attribute is true, then any classifier that is compatible with any of these constraining classifiers can be substituted; otherwise, it must be either one of these classifiers or their respective subclasses. If this property is empty, there are no constraints on the classifier that can be used as an argument. Issue 11239: Agreed. The statement should read: "make ValueSpecification::duration and ValueSpecification::timeExpression composites" Issue 10591: The issue seems quite valid, but is ValueSpecification (instead of Action) general enough? We need Oystein to comment on the thinking behind this one. I believe that the intent was to point to an action instance that had the necessary values specified; if so, it is a rather vague and indirect way to specify arguments. Issue 10820: I think that the real problem here is that the semantics of ports providing/requiring multiple interfaces are highly ambiguous. A much better solution to this problem is to limit the number to at most one required and/or provided interface per port. This will remove the ambiguity in both the connection and the semantics of ports. This issue needs to be addressed in depth. Issue 9003: Agreed, but we need to understand the impact of this on implementations on users and existing tools. Issue 9834: Although this proposal sounds reasonable, it should be clear that this is merely an optimization intended to make the jobs of tool builders easier; it is transparent to UML modelers. Therefore, a change like this should be assessed in terms of its impact on existing models and tools. For example, if the impact is backward compatibility issues between models of different versions or to bulking up of models due to additional data per model element, then I dont think it is worth the effort. I am also concerned with the possibility of introducing additional semantic conflicts between the current definition of these elements and the new generalization. How can we be confident that such conflicts will not be created? Unless we have reassurances of this type, it seems to me that this is more trouble than it's worth. Issues 8077, 9961, 9962: These too look like optimizations that are really only of benefit to tool builders, and not necessarily all of them. Modeler's can create links in their model currently and are not overly concerned with whether the repository names the result Link or InstanceSpecification. This may not be worth the disruption that it introduces. Issue 10819: I have already commented on this one. I agree that there are problems here that need to be resolved; but, as I said, I think that this is a key architectural issue that should be addressed in a systematic manner, rather than as some kind of local fix. Issue 10821: I agree that something needs to be done about this. However, I have concerns that the proposed resolution is too loose, since it allows any element to be named as a reference. It would be nice if this could be tightened in some way. I think we need to discuss this one further. ====================================================================== 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 "Nerijus Jankevicius" 08/24/2007 11:22 AM To cc Branislav Selic/Ottawa/IBM@IBMCA, "Pete Rivett" Subject updated resolutions for UML 2.2 Hello, See attached updated list of resolutions of some important UML 2.1.1 issues. Some issues requires quite important metamodel changes, so please start discussions on that. Any feedback is welcome. Thanks in advance, -- Nerijus Jankevicius Senior System Analyst No Magic Lithuanian Development Center[attachment "resolutions of UML2.2 issues.doc" deleted by Branislav Selic/Ottawa/IBM]