Issue 10821: ValueSpecification that refers to some Element shall be defined (uml2-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: ValueSpecification that refers to some Element shall be defined. It could be named ElementValue. We need that for tagged values that references to model elements. It could be used for Argument value also Resolution: Revised Text: Actions taken: February 23, 2007: received issue Discussion: End of Annotations:===== s is issue # 10821 ValueSpecification that refers to some Element shall be defined Subject: RE: issues 10821 - 10822 -- UML 2 RTF issues Date: Wed, 14 Mar 2007 20:39:04 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issues 10821 - 10822 -- UML 2 RTF issues Thread-Index: AcdmZDt4ShZ18qYlTNyGg4+hLfAMXwACfQWw From: "ESPINOZA Huascar 208501" To: "Juergen Boldt" , X-OriginalArrivalTime: 14 Mar 2007 19:39:04.0874 (UTC) FILETIME=[6CA918A0:01C76670] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Hi, Issue 10821 (see below) is also related to a problem in Figure 9.27 (formal/2007-02-03) I mentioned to Bran some time ago. Specifically, the parameter .brand. of .createCar. is passed as a parameter. On the other side, .brand. in .tire = brand. must be a kind of ValueSpecification. However, neither .LiteralString. nor .OpaqueExpression. create a formal link between these ValueSpecifications and the Parameter model element. So it.s not clear which kind of ValueSpecification is .brand. in .tire = brand.. If ElementValue is defined, this formal link can be established. Note that, for consistency, ElementValue should be parent of InstanceValue. Regards, ----------------------------------- Huascar ESPINOZA CEA SACLAY DRT/DTSI/SOL/LLSP Tel: +33 1 69 08 55 41 Fax: +33 1 69 08 20 82 91191 GIF/YVETTE CEDEX FRANCE ----------------------------------- -------------------------------------------------------------------------------- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : mercredi 14 mars 2007 19:10 À : issues@omg.org; uml2-rtf@omg.org Objet : issues 10821 - 10822 -- UML 2 RTF issues This is issue # 10821 From: "Nerijus Jankevicius" ValueSpecification that refers to some Element shall be defined ValueSpecification that refers to some Element shall be defined. It could be named ElementValue. We need that for tagged values that references to model elements. It could be used for Argument value also ======================================================= This is issue # 10822 From: "Nerijus Jankevicius" Ability to define "context specific" default values for Part Ability to define "context specific" default values for Part. It is widely used for system modeling (SysML), but it is not possible to map that to UML 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 Subject: RE: updated resolutions for UML 2.2 Date: Thu, 30 Aug 2007 06:20:19 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: updated resolutions for UML 2.2 Thread-Index: AcfmZICQCIpJxQ9DSaOaEX6xtxuLAgD4f5BA From: "Tim Weilkiens" To: "Nerijus Jankevicius" , Cc: "Branislav Selic" , "Pete Rivett" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l7U4Gau3006240 Hi Nerijus, my comments: Issue 10820: Assembly connector end Isn't there some kind of relationship between the provided and required interfaces to the contract property of the connector? I never tried to get to the bottom of that point, but I thought that the contract property specifies somehow which interfaces are used. Issue 10819: Diagram as NamedElement In principal I'm against storing diagram information in the model. I think it is important to strictly differentiate between model and diagram. That's an important concept. However we already introduced the Image for stereotypes. Maybe this issue is another necessary unwanted step. Isn't it possible to handle this information in the diagram interchange format? The diagram level is a model on its own that depends on the "real" model. Instead of incorparating diagram information into the metamodel we should use diagram interchange or define a new diagram model. Issue 10821: ElementValue What about using InstanceValue? It is a subclass of ValueSpecification and stores a reference to a enumeration literal, for instance. Tim > -----Original Message----- > From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > Sent: Friday, August 24, 2007 5:23 PM > To: uml2-rtf@omg.org > Cc: Branislav Selic; 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 > From: "Nerijus Jankevicius" To: "Tim Weilkiens" , Cc: "Branislav Selic" , "Pete Rivett" Subject: Re: updated resolutions for UML 2.2 Date: Fri, 31 Aug 2007 17:42:08 +0300 X-Mailer: Microsoft Windows Mail 6.0.6000.16480 Tim, See my comments below: Issue 10820: Assembly connector end Isn't there some kind of relationship between the provided and required interfaces to the contract property of the connector? "contract" property name sounds good, but is not what we need :), It is "The set of Behaviors that specify the valid interaction patterns across the connector". We need to know information which provided interface connected to which required one. Issue 10819: Diagram as NamedElement In principal I'm against storing diagram information in the model. You are absolutely right, it's not good to mix data and views. I suggest to create Diagram element just as reference or representation of some "diagram view".It should not contain any graphical information, we should leave that for DI standard. Diagram element could play role of mediator between data and views. All reasons why we need Diagram as element are listed in resolution text (packaging, stereotyping, dependencies). Issue 10821: ElementValue What about using InstanceValue? It is a subclass of ValueSpecification and stores a reference to a enumeration literal, for instance. InstanceValue could point only to ValueSpecification, but we need to reference Parameter, Property or Variable as arguments of message or any other call. InstanceValue could be subtype of ElementValue where "instance" redefines "element". Regards, -- Nerijus ----- Original Message ----- From: "Tim Weilkiens" To: "Nerijus Jankevicius" ; Cc: "Branislav Selic" ; "Pete Rivett" Sent: Thursday, August 30, 2007 7:20 AM Subject: RE: updated resolutions for UML 2.2 Hi Nerijus, my comments: Issue 10820: Assembly connector end Isn't there some kind of relationship between the provided and required interfaces to the contract property of the connector? I never tried to get to the bottom of that point, but I thought that the contract property specifies somehow which interfaces are used. Issue 10819: Diagram as NamedElement In principal I'm against storing diagram information in the model. I think it is important to strictly differentiate between model and diagram. That's an important concept. However we already introduced the Image for stereotypes. Maybe this issue is another necessary unwanted step. Isn't it possible to handle this information in the diagram interchange format? The diagram level is a model on its own that depends on the "real" model. Instead of incorparating diagram information into the metamodel we should use diagram interchange or define a new diagram model. Issue 10821: ElementValue What about using InstanceValue? It is a subclass of ValueSpecification and stores a reference to a enumeration literal, for instance. Tim -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Friday, August 24, 2007 5:23 PM To: uml2-rtf@omg.org Cc: Branislav Selic; 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 X-YMail-OSG: F6L1tA0VM1nIadjLCFsi5FBpwzBtiWsLUGdmpeQewzo4r2GaBvxM6FIwOKi6wSsY7g-- Reply-To: From: "Thomas Weigert" To: "'Nerijus Jankevicius'" , "'Tim Weilkiens'" , Cc: "'Branislav Selic'" , "'Pete Rivett'" Subject: RE: updated resolutions for UML 2.2 (10821) Date: Fri, 31 Aug 2007 21:39:48 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acfr32xEUYI+MSCISnigJyjbz2KUlwAYRTFw I agree with Nerijus that there is a problem with when a message draws its arguments from the dynamic value held in a parameter or attribute. However, the resolution proposed is, I believe, not quite the right approach. What Oystein had in mind was to indicate the run-time value of these elements (attribute, parameter). These are also referred to in the action metamodel. Adding a new subtype of value specification which represents the dynamic value of an associated element would work, but I believe we need to strive for consistency with the action model here. If the route of ElementValue is chosen, the new element needs to have a much better defined semantics, as the spirit (represents the run-time value of an element) is not really expressed in the resolution. Further, it probably is too broad. Not any element is suitable here, but only those who are able to function as "locations" that is holders of dynamic values. 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] ValueSpecification that refers to some Element shall be defined. It could be named ElementValue. We need that for tagged values that references to model elements. It could be used for Argument value also