Issue 9961: navigating from link to link ends (uml2-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: It is not possible to navigate from link to connected instances if slots are not created or Association is not assigned as type. Is it possible to create slots in instance of Association even if properties are owned in connected Classes? Are they required? Are they for navigating? Resolution: Revised Text: Actions taken: July 25, 2006: received issue Discussion: End of Annotations:===== m: "Nerijus Jankevicius" To: , "'Ed Seidewitz'" , "Juergen Boldt" Cc: Subject: Re: link ends Date: Tue, 25 Jul 2006 17:00:19 +0300 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Juergen, Issue #1 - navigating from link to link ends It is not possible to navigate from link to connected instances if slots are not created or Association is not assigned as type. 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] Is it possible to create slots in instance of Association even if properties are owned in connected Classes? Are they required? Are they for navigating?