Issue 3391: UML 1.4 RTF Issue: Multiple languages for uninterpreted strings (uml2-superstructure-ftf) Source: ObjectSwitch (Mr. Conrad Bock, conrad.bock(at)objectswitch.com) Nature: Uncategorized Issue Severity: Summary: Multiple languages for uninterpreted strings The various places that uninterpreted strings are used in UML should support multiple languages. For example, the Expression metaclass has an metaattribute for language and another for the uninterpreted string. This should be a set of such pairs. Then code generators can target multiple languages from the same model. Resolution: resolved, see above Revised Text: Actions taken: March 1, 2000: received issue March 8, 2005: closed issue Discussion: In Figure 13 and the entry for OpaqueExpression in Classes, change the multiplicities of the attributes of OpaqueExpression as follows: body : String [1..*] {ordered} language : String * {ordered} In OpaqueExpression in Classes: Description, Replace "a language-specific text string" with "language-specific text strings" Replace "of the language" with "of the languages". Attributes Entry for body attribute, at end of text, add ", possibly in multiple languages". Entry for language attribute, replace "language" with "languages", and "is unspecified" with "are unspecified". At end of text add new sentence "Languages are matched to body strings by order.". Semantics, Throughout, replace "language" with "languages", "body" with "bodies", "is unspecified" with "are unspecified". UML 2.0 Superstrucure FTF Final Report Document {Report document number} Page 57 At end of first sentence add new sentence, "Languages are matched to body strings by order.". Notation, First paragraph First sentence, replace first "a text string in a particular language" with "text strings in particular languages". Second sentence, replace "syntax of the string is" with "syntax of the strings are", and "linguistic analyzer for the language" with "linguistic analyzers for the languages". Third paragraph First sentence, replace "language" with "languages". Last sentence, at end, add "to which it corresponds.". Disposition: Resolved End of Annotations:===== From: "Conrad Bock" To: Subject: UML 1.4 RTF Issue: Multiple languages for uninterpreted strings Date: Wed, 1 Mar 2000 09:49:53 -0800 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: $fid9in\!!<+4!!8@L!! Juergen, Here's another UML 1.4 RTF issue. Conrad Multiple languages for uninterpreted strings The various places that uninterpreted strings are used in UML should support multiple languages. For example, the Expression metaclass has an metaattribute for language and another for the uninterpreted string. This should be a set of such pairs. Then code generators can target multiple languages from the same model. Subject: [issues 3391 and 2541] Classes Chapter Date: Fri, 12 Dec 2003 17:06:38 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [issues 3391 and 2541] Classes Chapter Thread-Index: AcPA/BabAACPi5DcQWWko7bCcHJvPg== From: "Karl Frank" To: X-OriginalArrivalTime: 12 Dec 2003 22:06:40.0068 (UTC) FILETIME=[38057840:01C3C0FC] As agreed in the FTF call this week, I am sending around some issues and proposed resolutions from the Classes chapter. Both issue 3391 and 2541 are to be proposed to be resolved by adding the quoted sentence below to the Semantics section for Opaque Expression. It should be noted that these issues were raised against the Expressions section, but that the late insertion of the OpaqueExpression appears to make OpaqueExpression the correct place for the correction. 'If the language attribute has the standard value "OCL", the body of the expression must be a syntactically correct and type correct OCL expression in the context of the Expression. The syntax and semantics of the expression is given by the OCL specification, currently OMG document number ptc/p3-10-14' Thanks to Anders Ivner for his help on this, and to Conrad Bock and an anonymous contributor for raising the issues. Feedback welcome. ------------- Karl Frank Borland Software Corporation cell: 978 853 3592 landline: 978 283 4656 15 Haskell Street Gloucester MA 01930 -------------------- The relevant parts of the spec for OpaqueExpression are: ================ OMG Issue No: 3391 Title: UML 1.4 RTF Issue: Multiple languages for uninterpreted strings Source: ObjectSwitch (Mr. Conrad Bock, conrad.bock@objectswitch.com) Summary: Multiple languages for uninterpreted strings The various places that uninterpreted strings are used in UML should support multiple languages. For example, the Expression metaclass has an metaattribute for language and another for the uninterpreted string. This should be a set of such pairs. Then code generators can target multiple languages from the same model. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved ----------------------------------- OMG Issue No: 2541 Title: Datatypes: Expression Source: Summary: the metaclass Expression includes an attribute called "language" of type Name. To enable tools to check OCL expressions, it is neccesary to define a standard value for this attribute, which denotes the fact that the expressions is an OCL expression. Without such a standard defined value tools cannot distinguish OCL expresions and cannot interpret them (for purposes of typechecking, code generation, etc....) I propose to add the value "OCL" as a standard value for the attribute "language" of metaclass "Expression" to the chapter on datatypes. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Disposition: Unresolved OMG Issue No: 3391 Title: UML 1.4 RTF Issue: Multiple languages for uninterpreted strings Source: ObjectSwitch (Mr. Conrad Bock, conrad.bock@objectswitch.com) Summary: Multiple languages for uninterpreted strings The various places that uninterpreted strings are used in UML should support multiple languages. For example, the Expression metaclass has an metaattribute for language and another for the uninterpreted string. This should be a set of such pairs. Then code generators can target multiple languages from the same model. Discussion: In UML 2.0, the concept of uninterpreted string is modeled by OpaqueExpression, which has a .language. attribute for the above purpose. Disposition: Resolved OMG Issue No: 3391 Title: UML 1.4 RTF Issue: Multiple languages for uninterpreted strings Source: ObjectSwitch (Mr. Conrad Bock, conrad.bock@objectswitch.com) Summary: Multiple languages for uninterpreted strings The various places that uninterpreted strings are used in UML should support multiple languages. For example, the Expression metaclass has an metaattribute for language and another for the uninterpreted string. This should be a set of such pairs. Then code generators can target multiple languages from the same model. Discussion: This issue was raised in the context of UML 1.x. However, in UML 2.0, the concept of uninterpreted string is modeled by OpaqueExpression, which has a .language. attribute for the above purpose. However, in addition to this, there are several places in the spec, where a string is used to specify some part of a model, where there is no way to identify the language used to interpret the string. This is the case for the following concepts: · In Expression, the .symbol. that identifies the operator used in the expression should also include a .language. attribute. · In Parameter, a string is used to identify the default value of the Parameter. · In Property, a string is used to identify the default value of a Property. One possibility is to add a language attribute to accompany each string. Alternatively, it can be assumed that these specifications are being defined in a context where the language has been identified by other means. However, this does not allow mixing of different languages in a single model. To support this kind of flexibility, it is necessary to add a .language. attribute in each of these cases. This implies the following changes. In the Infrastructure Specification · In figure 30 on page 54, add an attribute .language : String [0..1]. to the metaclass Expression. · On page 55, add the following attribute in the Attributes subsection of Expression: · language : String[0..1] The language in which the symbol attribute is specified. · In figure 43 on page 196, add an attribute .language : String [0..1]. to the metaclass Parameter. · On page 161, add the following attribute in the Attributes subsection of Parameter: · language : String[0..1] The language in which the default value attribute is specified. In the Superstructure Specification · In figure 13 on page 45, add an attribute .language : String [0..1]. to the metaclass Expression. · On page 45, add the following attribute in the Attributes subsection of Expression: · language : String[0..1] The language in which the symbol attribute is specified. · In figure 28 on page 74, add an attribute .language : String [0..1]. to the metaclass Parameter after the attribute ./default.. · On page 161, add the following attribute in the Attributes subsection of Parameter after the attribute ./default.: · language : String[0..1] The language in which the default value attribute is specified. · In figure 30 on page 80, add an attribute .language : String [0..1]. to the metaclass Property after the attribute ./default.. · On page 89, add the following attribute in the Attributes subsection of Property after the attribute ./default.: · language : String[0..1] The language in which the default value attribute is specified. Disposition: Resolved Reply-To: From: "Conrad Bock" To: , Subject: RE: More resolutions for Ballot 19 from Bran Date: Wed, 14 Jul 2004 16:34:54 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, Some comments on your ballot 19 resolutions. Conrad - Issue 2582 (class EnumerationLiteral issue) A data types could be a struct that points to objects, so I don't think the constraint is correct. In any case, it isn't what the issue is about. - Issue 3391 (Multiple languages for uninterpreted strings) The issue is asking for the various body/language string attributes to support multiple languages, for example by both being multi-valued and ordered. The resolution addresses a different issue. - Issue 4448 (Does visibility apply to creating an destroying links?) Agreed, visibility is a design-time concept, but so are actions, ie, they exist in the model. The purpose of visibility is to constrain models not to specify actions that violate it. For example, if an attribute is private, there shouldn't be a ReadStructuralFeature action in a method of another object that access the private attribute. Since links can affect objects in UML 2, the issue asks if visibility applies to manipulating them To: Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: More resolutions for Ballot 19 from Bran X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Wed, 14 Jul 2004 22:29:55 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 07/14/2004 22:29:59, Serialize complete at 07/14/2004 22:29:59 Thanks, Conrad for reviewing these. Some responses and some questions embedded below: > - Issue 2582 (class EnumerationLiteral issue) > > A data types could be a struct that points to objects, so I don't > think the constraint is correct. In any case, it isn't what the > issue is about. A pointer to an object (Instancevalue) is still a kind of DataType, so the constraint still looks valid to me. I agree that the issue was not about that directly, but I thought it useful to add that constraint, because it is implicit in the issue. Alternatively, I can take the constraint out and close the issue "No change". What do you think? > - Issue 3391 (Multiple languages for uninterpreted strings) > > The issue is asking for the various body/language string > attributes to support multiple languages, for example by both > being multi-valued and ordered. The resolution addresses a > different issue. That's not how I read it, but since you raised the issue, I am sure you know what you meant. What resolution do you propose? > - Issue 4448 (Does visibility apply to creating an destroying links?) > > Agreed, visibility is a design-time concept, but so are actions, > ie, they exist in the model. The purpose of visibility is to > constrain models not to specify actions that violate it. For > example, if an attribute is private, there shouldn't be a > ReadStructuralFeature action in a method of another object that > access the private attribute. Since links can affect objects in > UML 2, the issue asks if visibility applies to manipulating them > also. And, the answer is that it does not -- perhaps I should make that clearer. You seem to be implying some kind of capability mechanism that keeps visibility information around at run time. I think that this is assuming too much. Thanks again....Bran Reply-To: From: "Conrad Bock" To: , Subject: RE: More resolutions for Ballot 19 from Bran Date: Thu, 15 Jul 2004 15:44:26 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Followup discussion below, Conrad > > - Issue 2582 (class EnumerationLiteral issue) > > A data types could be a struct that points to objects, so I don't > > think the constraint is correct. In any case, it isn't what > > the issue is about. > A pointer to an object (Instancevalue) is still a kind of DataType, > so the constraint still looks valid to me. OK, that makes sense. > What do you think? > > > - Issue 3391 (Multiple languages for uninterpreted strings) > > > > The issue is asking for the various body/language string > > attributes to support multiple languages, for example by both > > being multi-valued and ordered. The resolution addresses a > > different issue. > > That's not how I read it, but since you raised the issue, I am > sure you know what you meant. What resolution do you propose? I think the various places that have body/language attributes should be: body : String [1..*] {ordered} language : String [0..*] {ordered} So multiple strings can be specified in multiple languages. The body and language strings would be matched by order. > > - Issue 4448 (Does visibility apply to creating an destroying links?) > > > > Agreed, visibility is a design-time concept, but so are actions, > > ie, they exist in the model. The purpose of visibility is to > > constrain models not to specify actions that violate it. For > > example, if an attribute is private, there shouldn't be a > > ReadStructuralFeature action in a method of another object that > > access the private attribute. Since links can affect objects in > > UML 2, the issue asks if visibility applies to manipulating them > > also. > And, the answer is that it does not -- perhaps I should make > that clearer. You seem to be implying some kind of capability > mechanism that keeps visibility information around at run time. > I think that this is assuming too much. Visibility only applies to design time, as you said, we're in agreeement on that. I'm saying design time is when actions are created, ie, when the metaclass CreateLinkAction is instantiated, etc. Visibility applies to where those instances of CreateLinkAction, etc, can be put. For example, an instance of ReadStructuralFeatureAction for a private attribute cannot be put in an activity used as a method for a class other than the one on which the attribute is declared. Visibility is a well-formedness rule on user-level models. I personally think if ReadStructuralFeatureAction must obey visibility, as it does curerently, that CreateLinkAction should, at least in the From: "Thomas Weigert" To: , , Subject: RE: More resolutions for Ballot 19 from Bran Date: Thu, 15 Jul 2004 14:52:58 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) So which of these bodies is executed (e.g., if that is an opaque behavior)? What if they are inconsistent? I think that is a can of worms we don't need to open... Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Thursday, July 15, 2004 2:44 PM > To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org > Subject: RE: More resolutions for Ballot 19 from Bran > > > > I think the various places that have body/language attributes should > be: > > body : String [1..*] {ordered} > language : String [0..*] {ordered} > > So multiple strings can be specified in multiple languages. The body > and language strings would be matched by order. > Reply-To: From: "Conrad Bock" To: , Subject: RE: More resolutions for Ballot 19 from Bran Date: Thu, 15 Jul 2004 16:00:13 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > So which of these bodies is executed (e.g., if that is an opaque > behavior)? Presumably whichever one is in the language being used by the generator. > What if they are inconsistent? Lots of things in models can be inconsistent, that't the user's problem. If we're going to have uninterpreted strings, and we're supporting model compilation to various targets, we need to have multiple unintepreted strings in multiple languages. Conrad From: "Thomas Weigert" To: , , Subject: RE: More resolutions for Ballot 19 from Bran Date: Thu, 15 Jul 2004 15:14:22 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) How does multiple targets imply multiple languages for the SAME behavior? Is this really a requirement? Thanks, Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Thursday, July 15, 2004 3:00 PM > To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org > Subject: RE: More resolutions for Ballot 19 from Bran > > > > Thomas, > > > So which of these bodies is executed (e.g., if that is an opaque > > behavior)? > > Presumably whichever one is in the language being used by the > generator. > > > What if they are inconsistent? > > Lots of things in models can be inconsistent, that't the user's > problem. > > If we're going to have uninterpreted strings, and we're supporting model > compilation to various targets, we need to have multiple unintepreted > strings in multiple languages. > > Conrad > Reply-To: From: "Conrad Bock" To: , Subject: RE: More resolutions for Ballot 19 from Bran Date: Thu, 15 Jul 2004 16:22:53 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) > How does multiple targets imply multiple languages for the SAME > behavior? One model => multiple targets. The same behavior can compile to many machines, which may mean many languages. If the behavior is opaque, then you need a way to specify the behavior on each target. That's the point of uninterpreted strings: the model compiler can't do the work of translating to the target, so the modeler needs to do it. Conrad Reply-To: From: "Conrad Bock" To: , Subject: RE: Draft of ballot 23 -- pelase review Date: Thu, 12 Aug 2004 17:27:15 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Comments on draft ballot 23. Conrad - 3391 (Multiple languages for uninterpreted strings) I thoought you assigned this to me for ballot 24. I have the write up already and will post with the others for ballot 24. - 6682 (See CommonBehavior for a description of Event specifications) Is there a convenience document for this one? Not sure why classifiers, events, and behaviors are the primary categories. Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: ,av,,ac, Activity/action resolutions for ballot 24 Date: Sun, 15 Aug 2004 16:15:25 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi all, Here are proposed activity/action resolutions for ballot 24. One is for a class issue Bran assigned to me (3391). A couple are for recent issues that don't have numbers yet, will post an update later. Conrad issueresolution-cb-12.doc OMG Issue No: 3391 Title: UML 1.4 RTF Issue: Multiple languages for uninterpreted strings Source: ObjectSwitch (Mr. Conrad Bock, conrad.bock@objectswitch.com) Summary: Multiple languages for uninterpreted strings The various places that uninterpreted strings are used in UML should support multiple languages. For example, the Expression metaclass has an metaattribute for language and another for the uninterpreted string. This should be a set of such pairs. Then code generators can target multiple languages from the same model. Discussion: In Figure 13 and the entry for OpaqueExpression in Classes, change the multiplicities of the attributes of OpaqueExpression as follows: body : String [1..*] {ordered} language : String * {ordered} In OpaqueExpression in Classes: Description, Replace "a language-specific text string" with "language-specific text strings" Replace "of the language" with "of the languages". Attributes Entry for body attribute, at end of text, add ", possibly in multiple languages". Entry for language attribute, replace "language" with "languages", and "is unspecified" with "are unspecified". At end of text add new sentence "Languages are matched to body strings by order.". Semantics, Throughout, replace "language" with "languages", "body" with "bodies", "is unspecified" with "are unspecified". At end of first sentence add new sentence, "Languages are matched to body strings by order.". Notation, First paragraph First sentence, replace first "a text string in a particular language" with "text strings in particular languages". Second sentence, replace "syntax of the string is" with "syntax of the strings are", and "linguistic analyzer for the language" with "linguistic analyzers for the languages". Third paragraph First sentence, replace "language" with "languages". Last sentence, at end, add "to which it corresponds.". Disposition: Resolved OMG Issue No: 6114 Title: State extension Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: State should be an extension of type rather than object node. Discussion: This requires more discussion on what should be specifiable as a type, and layering the state machine model (issue 7555). Disposition: Defer OMG Issue No: 6348 Title: Control pins Source: Oracle (Dr. Guus Ramackers, guus.ramackers@oracle.com) Summary: There should be a special kind of pin for control tokens. This will allow parameter sets to be used with control, for example. Also resolves issue of where control is bufferred when it is direceted at a join. Can be implemented as a pin that has no parameter, by making them the last in the ordering of pins, so no parameter corresponds to them. This is also a request of the SysML team. Discussion: Using control with parameter sets requires a user-level type for control, which could be used with parameters. Since UML does not standardize a user-level model library, the resolution below allows it to be indicated on ObjectNode. To address the other half of the issue requires that pins be marked as control for the action, rather than data. Figure 187 of the FAS, ObjectNode, add the attribute isControlType : Boolean = false In ObjectNode class: Description, second paragraph: Remove .and.. At end of sentence, add ., and carrying control values.. Attributes (CompleteActivities) add entry: isControlType : Boolean = false Tells whether the type of the object node is to be treated as control. Semantics (CompleteActivities), add new paragraph at end: An object node may indicate that its type is to be treated as a control value, even if no type is specified for the node. Control edges may be used with the object node having control type. Notation Under Figure 275 of the FAS, paragraph beginning "(CompleteActivities)", third sentence, replace "and ordering" with ", ordering, and control type". After Figure 187, add new figure with caption: Control pins In Pin class, Change title of "Attributes" section to "Attributes (CompleteActivities)", and add new entry: isControl : Boolean = false Tells whether the pins provides data to the actions, or just controls when it executes it. Add new section "Constraints (CompleteActivities), with new constraint: [1] Control pins have a control type. isControl implies isControlType Semantics, add new paragraph at end: "(CompleteActivities) Control pins always have a control type, so they can be used with control edges. Control pins are ignored in the constraints that actions place on pins, including matching to behavior parameters for actions that invoke behaviors. Tokens arriving at control input pins have the same semantics as control arriving at an action, except that control tokens can queue up in control pins. Tokens are placed on control output pins according to the same semantics as tokens placed on control edges coming out of actions." Notation Just before the last sentence of the section, in its own paragraph, add "(CompleteActivities) Control pins are shown with a text annotation placed near the pin symbol {control}.". In ControlFlow class, Constraints, change first constraint to: [1] Control flows may not have object nodes at either end, except for object nodes with control type. Disposition: Resolved OMG Issue No: 6368 Title: Join nodes that destroy tokens Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Would be useful if join nodes optionally destroyed tokens not accepted, especially when using join expressions. Discussion: This requires more discussion of examples. Disposition: Defer OMG Issue No: 6487 Title: Conditions for parameter sets Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: Selection behavior on object nodes should be changed to allow execution at insertion time, keeping the queue Discussion: This issue should be titled .Selection behavior... Requires more discussion on how to express sorting procedures in the model. Disposition: Defer OMG Issue No: 7337 Title: inconsistency in the action model Source: Motorola (Dr. Thomas Weigert, thomas.weigert@motorola.com) Summary: There is an inconsistency in the action model between actions for StructuralFeatures in general, and actions operating on links. The family of structural feature action, such as WriteStructuralFeatureAction, are defined for any kind of structural feature. Consequentially, these actions can manipulate values that are not due to attributes or assication ends (both special cases of Property) but of any kind of StructuralFeature. However, actions defined for links can only operate on links that are due to associations in the model. This because LinkEnd is identified through the association to a Property (named "end"). However, there are other links in the model, such as those due to Connectors. To make these consistent, one either should limit the structural feature actions to apply to Properties (rather than StructuralFeatures), or one should generalize the link actions to apply to liks identified by any StructuralFeature, not just to links identified by Properties. This difference in generality does, of course, not matter for the UML as defined, but it could hamper the deployment of actions to profiles that define other kinds of links. (This is, luckily, not a problem for links due to Connectors, as we can argue that for links due to connectors that are not explicitly typed, these are identified by the ends of the derived associations.) Discussion: Two comments on the issue text: "there are other links in the model, such as those due to Connectors". The links established due to connectors are just links any other (link = an instance of an association). "or one should generalize the link actions to apply to liks identified by any StructuralFeature". Links cannot be identified by structural features that are not association ends, because there are no links in that case. In separate discussion with the filer, there was concern that structural feature were not well enough defined to have actions defined on them. Structural feature inherits from TypedElement, which provides a way to map to instances of a type, as explained in the entry for Kernel::TypedElement. The structural feature actions provide the results of this mapping, as explained in the semantics of StructuralFeature. The filer would like this issue held for further discussion. Disposition: Defer OMG Issue No: 7373 Title: attribute Activity.isSingleExecution Source: Motorola (Dr. Thomas Weigert, thomas.weigert@motorola.com) Summary: The attribute Activity.isSingleExecution creates, for activities, something akin to what the difference is between behavior as BehavioredClassifier.classifierBehavior vs. behavior as method of a behavioral feature. In the former case, there is exactly one execution during the life of the classifier (and the behavior would accept many tokens), while in the latter there is one execution for every invocation. Activity should not confusingly add another means of doing the same thing. At minimum, it should be explained what the effect of this attribute is when dealing with classifier behavior vs. method. In particular, it is very confusing what it would mean to have a behavior that is its own context and uses a separate execution for each token. Further, the definition of the attribute: "If true, tokens from separate invocations of the activity may interact" is completely meaningless as a definition. Discussion: Activity.isSingleExecution = true is not equivalant to a BehavioredClassifier. A BehavioredClassifier can have many instances, each with their own execution. An activity with isSingleExecution = true means that there is at most one execution of the activity, and all invocations of it feed values into that execution, even if the behavior is a method. This is explained in the semantics of Activity, on on p 287 in more detail than referred to in the issue, including the relation to classifier behaviors. The issue refers to "a separate execution for each token", but presumably meant to say "for each invocation", per the definition of isSingleExecution. When a behavior is its own context, and isSingleExecution = false, there is a separate context for each execution of the behavior, even if these executions are going on concurrently. This is typical for function calls in common programming languages, because each call uses a separate stack frame. In UML, this is expressed by behaviors being classes and their executions being instances of those classes. isSingleExecution = true means the behavior is a singleton class. The definition of the attribute needs clarification, update as follows. In Activity class, Attributes (CompleteActivities) Change text of entry for isSingleExecution to: "If true, all invocations of the activity are handled by the same execution." Semantics: In the paragraph beginning "(CompleteActivities) Each time an activity is invoked,", after the sentence ending "handles all orders.", add new sentence "This applies even if the behavior is a method, for example, on each order." In paragraph beginning "If a separate execution of the activity": Replace "with a context classifier, but that is not a method," with "that is the behavior of a classifier". Add new sentence after the second one: "The same is true for modeling methods in common programming languages, which have separate stack frames for each method call. Disposition: Resolved OMG Issue No: 7394 Title: Variable pins Extend input and output pins to get and set variables Source: International Business Machines (Dr. Tracy Gardner, tgardner@uk.ibm.com) Summary: Variable pins Extend input and output pins to get and set variables. Discussion: This is partly a special case of a more general need for input pins to refer to actions with one output, without using flows. The resolution below does this for input pins, provides presentations options for setting variable values from output pins, and for flows between pins and parameter nodes. The resolution is written assuming the resolution of 7319. In Actions, in overview section for Basic Concepts, as amended by 7319, first paragraph, replace the last sentence with: The values that are the inputs to an action may be described by value specifications, obtained from the output of actions that have one output (in StructuredActions), or in ways specific to the behaviors that use them, for example, the activity flow model supports providing inputs to actions from the outputs of other actions. In Actions, in overview section for Structured Concepts, as introduced by 7319, first paragraph, add to end of last sentence: .and a kind of input pin is defined for accepting the output of an action without using flows.. In Actions, in abstract syntax diagrams, at the end of the section on structured actions as introduced by the resolution of 7319, insert a new figure and caption adding a new subtype of InputPin, as shown below: Action input pin Add new class ActionInput Pin in StructuredActions. ActionInputPin An action input pin is a kind of pin that executes an action to determine the values to input to another. Attributes None. Associations fromAction : Action [1] The action used to provide values. Constraints [1] The fromAction of an action input pin must have exactly one output pin. [2] The fromAction of an action input pin must only have action input pins as input pins. [3] The fromAction of an action input pin cannot have control or data flows coming into or out of it or its pins. Semantics If an action is otherwise enabled, the fromActions on action input pins are enabled. The outputs of these are used as the values of the corresponding input pins. The process recurs on the inputs pins of the fromActions, if they also have action input pins. The recursion bottoms out at actions that have no inputs, such as for read variables or the self object. This forms a tree that is an action model for nested expressions. Notation None. Examples Example (in action language provided just for example, not normative): self.foo->bar(self.baz); meaning get the foo attribute of self, then send a bar signal to it with argument from the baz attribute of self. The repository model is shown below. Rationale ActionInputPin is introduced to pass values between actions in expressions, without using flows. In Activities, introduce new class entries as follows, to add notation: ActionInputPin (as specialized) See ActionInputPin in Actions. Attributes None. Associations None. Constraints None. Semantics See ActionInputPin in Actions. Notation An action input pin with a ReadVariableAction as a fromAction is notated as an input pin with the variable name written beside it. An action input pin with a ReadSelfObject as a fromAction is notated as an input pin with the word .self. written beside it. An action input pin with a ValueSpecification as a fromAction is notated as an input pin with the value specification written beside it. Examples See ActionInputPin in Actions. Rationale AddVariableValueAction (as specialized) See AddVariableValueAction in Actions. Attributes None. Associations None. Constraints None. Semantics See AddVariableValueAction in Actions. Notation Presentation Option The presentation option at the top of the figure below may be used as notation for a model corresponding to the notation at the bottom of the figure. If the action has non-defaulted metaattribute values, these can be shown with a property list near the variable name. Presentation option for AddVariableValueAction Examples Rationale In Activities, ActivityParameterNode, Presentation Option, after paragraph added by resolution of 6140, add a new paragraph, figure, and caption as follows: . .The presentation option at the top of the activity diagram below may be used as notation for a model corresponding to the notation at the bottom of the diagram.. Presentation option for flows between pins and parameter nodes In Activities, InitialNode, Semantics, second paragraph, in sentence added at end by the resolution of 7319, after .(see Exception Handler). add .are fromActions of action input pins,.. Disposition: Resolved OMG Issue No: 7554 Title: Attribute scope is of type StructuredActivityNode instead of StructuredActi Source: Oose.de (Mr. Tim Weilkiens, tim.weilkiens@oose.de) Attribute scope is of type StructuredActivityNode instead of StructuredActivityGroup Discussion: In Variable class, Attributes, entry for scope, change the type to StructuredActivityNode. Disposition: Resolved OMG Issue No: 7562 Title: ReadSelfAction Source: Oose.de (Mr. Tim Weilkiens, tim.weilkiens@oose.de) ReadSelfAction has the contraint: "The action must be contained in an activity that has a host classifier." On the other hand the semantic section describes: "For activities that have no other context object, the activity itself is the context object." A ReadSelfAction within an activity without a host classifier object returns the activity object. So the constraint is superfluous. Discussion: This was fixed as part of 7319. Disposition: Resolved OMG Issue No: 7620 Title: Coupling between StateMachines and Activities Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) ReadSelfAction has the contraint: "The action must be contained in an activity that has a host classifier." On the other hand the semantic section describes: "For activities that have no other context object, the activity itself is the context object." A ReadSelfAction within an activity without a host classifier object returns the activity object. So the constraint is superfluous. Discussion: This is deferred for the same reasons as 6114. Disposition: Defer OMG Issue No: ???? Title: The resolution to issue 6093 removed too much constraint. Source: University of Paderborn (Mr. Jan Hendrik Hausmann, hausmann@upb.de) The resolution to issue 6093 removed too much constraint. It should be left in place for decision, merge, and fork nodes. Discussion: In DecisionNode, Constraints, add the following constraint: [] The edges coming into and out of a decision node must be either all object flows or all control flows. In ForkNode, Constraints, add the following constraint: [] The edges coming into and out of a fork node must be either all object flows or all control flows. In MergeNode, Constraints, add the following constraint: [] The edges coming into and out of a merge node must be either all object flows or all control flows. In JoinNode, Constraints, add the following constraint: [] If a join node has an incoming object flow, it must have an outgoing object flow, otherwise, it must have an outgoing control flow. Disposition: Resolved OMG Issue No: ???? Title: Incorrect constraints on Pin and ObjectFlow Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov) On Pin, the constraint isUnique = false introduced by 6090 should be on ObjectNode, and the text should be "Object nodes are not unique typed elements." On ObjectFlow, Constraints (BasicActivities), rule 1 still reflects the time when pins were connected to actions by flows, during the submission process. It should be "Object flows may not have actions at either end.". Discussion: In Pin class, Constraints, rule introduced by issue 6090 (isUnique = false), move the rule to ObjectNode, and change text to "Object nodes are not unique typed elements." In ObjectFlow class, Constraints (BasicActivities), change rule 1 to "Object flows may not have actions at either end.". Disposition: Resolved ubject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 02:22:18 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 24 draft Thread-Index: AcSGUaOOvWEvXmwvTEeA2cPkA+ZL9gAHR9rg Priority: Urgent From: "Pete Rivett" To: "Branislav Selic" , , X-Virus-Scanned: by amavisd-new at sentraliant.com 3391: I don't really like the idea of 2 separate sequences (one for body one for language) which must be kept in sync. It seems to me each (body+language) pair should be a structure/tuple: was this considered? I don't think the resolution should be pulled just on my objection but do think that at the very minimum the language property should be unique; and there should be a constraint that the size of the 2 sequences must be equal. 3398: the discussion (and hence the disposition) do not address the issue raised which is that the XMI spec specifies a number of tags that may be attached to metamodel elements in order to tailor the XMI Schema or Documents. While most of these have sensible defaults, there are others that do not. Prime examples are the XML namespace URI (e.g. http://schema.omg.org/spec/UML/2.0) and the namespace prefix (e.g. UML). Such values should certainly be included in the XMI for the metamodel and also in the specification document (a good place would be Appendix F). 5977: two problems are raised by the resolution: a) isUnique=true is the default for MultiplicityElement so we have a problem in that AFAIK (looking at resolution to 7575 in this set of issues) there is no notation to specify non-default multiplicity: the of {unique} is pointless since that's the default anyway! b) whether or not {nonunique} has an explicit notation the point raised by the issue still stands at the metamodel level: there should be a constraint to say that if one end of an association has isUnique=false then the other end must also have isUnique=false. 5979: also requires an Infra change 6171: In the last sentence, rather than saying 'Such rules are beyond the scope of UML' could they not be made a semantic variation point? A precedent is in 7.8.3 where there is a SVP related to compatibility of redefinitions. (I don't feel strongly about this) 6409, 6430, 6452: The discussion gives the reason for deferral as the OCL 2.0 spec not having been adopted; in fact it was adopted at the same time as Super. The declared intention of the submission teams on adoption was for the FTFs to perform a reconciliation between the largely stable adopted specs: OCL in particular has had virtually no changes. In any case the differences in OCL 2.0 are not great and it is not the case AFAIK that 'the vast majority of constraints are likely have to be rewritten'. If we've run out of time let's say that rather than raise unwarranted concerns (e.g. to AB) that major reconciliation work is still required with OCL. 6616: (minor typo) the discussion states: "and provides yet another way to introduce inconsistencies into a model, declaring a node a root when it in fact has children." In fact the inconsistency would be if the node had parent(s) 6630: I'm not very happy with the resolution since it continues to ignore the point I've been trying to make about the distinction between navigability and ownership (you can have navigability without an owned property): and I did not see any objection to my proposal of using the new dot notation to show non-ownership. It would be nice to have a response to that though I will not continue to object on this point. However I do strongly object to removing the name of association end supplierDependency on the basis that " by naming the supplierDependency end, the metamodel would invite constraints to be written involving it, etc". (this from an email between those word-smithing the issue) My objections are: a) the issue did not cite any problem with this being named b) I think it's acknowledged that some tools at least would like to do 'where used' navigations - and recent discussions on MDA have stressed the need for traceability: removing the association end name is actively hostile to such tools c) the only people who will be writing constraints on this association end would be ourselves or a successor RTF d) taking this rule as a precedent would involve deleting large numbers of other association end names from the metamodel. e) the resolution does not even make explicit that this name is being removed 7400: Misses the point of the issue: I wrote an email to explain the issue and the change needed (which is to have AssociationClass::ownedEnd subsetting AssociationClass::ownedAttribute). Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, 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 -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, August 19, 2004 7:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 draft Attached, please find the draft of ballot 24. There are 66 resolutions in this one -- good work! Reminder: voting on this ballot will commence on Friday at 6 pm EDT. If you have any complaints or suggestions, please submit them by tomorrow noon EDT. Regards, Bran