Issue 14522: OpaqueBehavior::opaqueBehavior should be OpaqueBehavior::language (fuml-ftf) Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com) Nature: Uncategorized Issue Severity: Summary: Specification: Semantics of a Foundational Subset for Executable UML Models (ptc/2008-11-03) Subclause: 7.3.2.2.4 OpaqueBehavior The OpaqueBehavior::opaqueBehavior attribute should instead be “language”, consistent with the UML 2.2 specification. Resolution: Agreed. Revised Text: see page 60 of OMG document ptc/2009-10-02 Actions taken: October 6, 2009: received issue July 23, 2010: closed issue Discussion: End of Annotations:===== ubject: OpaqueBehavior::opaqueBehavior should be OpaqueBehavior::language Date: Tue, 6 Oct 2009 16:42:00 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OpaqueBehavior::opaqueBehavior should be OpaqueBehavior::language thread-index: AcpGxXQiF4TAGAMbT/Co1Zbaa5jobg== From: "Ed Seidewitz" To: Specification: Semantics of a Foundational Subset for Executable UML Models (ptc/2008-11-03) Subclause: 7.3.2.2.4 OpaqueBehavior The OpaqueBehavior::opaqueBehavior attribute should instead be .language., consistent with the UML 2.2 specification. From: "Rouquette, Nicolas F (316A)" To: Ed Seidewitz CC: "fuml-ftf@omg.org" Date: Fri, 23 Oct 2009 00:16:23 -0700 Subject: Re: DRAFT fUML Ballot 2 Thread-Topic: DRAFT fUML Ballot 2 Thread-Index: AcpOgdo1lCYQ0ymoSu2WLGwwYVhrWwELoFywACiR1BMACoMEoAANArEt Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized On 10/22/09 7:24 PM, "Ed Seidewitz" wrote: Nicolas . Thanks for the comments. Here are some responses. Issue 13883: Receptions should never be abstract You commented: Why? A BehavioralFeature is redefinable. There could be a practical utility in having abstract receptions used to specify, as an interface, the set of signals that an active class can receive. I disagree with this issue. BehavioralFeature is, indeed, a descendant of RedefinableElement. However, RedefinableElement::redefinedElement is a derived union, which must be subsetted in a concrete subclass to provide the actual redefinition (as in, e.g., Operation::redefinedOperation). However, no such subset attribute is provided for Reception, so it is not actually possible to redefine a reception, as stated in the issue. It would thus never be possible to redefine an abstract reception as non-abstract. Also, you mention interfaces in your comment, but fUML does not include interfaces nor interface realization. This issue only applies to fUML, so interfaces are not relevant. NFR: yes, fUML doesn.t have interfaces but I was thinking of interface in the following sense: An abstract class defining abstract receptions for abstract signals. Indeed, without something like Reception::redefinedReception { subsets RedefinableElement::redefinedElement }, it.s not possible to have abstract receptions. This seems to me an oversight in the UML and I suggest we add something to this effect in the resolution paragraph and file an issue against the UML. Regrettably, I have to agree that the outcome remains unchanged. Issue 14521: A data type should not be allowed to have operations You commented: Then how does one specify the legal operations one can perform on instances of a given DataType? This seems inconsistent with clause 9.1 where , e.g., Integer is a Primitive Datatype, i.e., a kind of DataType. How then does one specify that the primitive behaviors defined in 9.2 are the operations one can perform on an instance of Integer as a datatype? I disagree with this issue. The primitive behaviors in Clause 9.2 are specifically not operations of the data type. They are standalone behaviors that take instances of the data type as arguments. You can confirm this in the normative XMI for the fUML Foundation Model Library (it is unfortunately that there is no standard graphical notation for behaviors as packaged elements.). In any case, the Operation::zero_or_one constraint requires (in fUML) that every non-abstract operation have a method . this is required for operational dispatching to work. However, as the issue notes, data types are not behaviored classifiers, so they cannot own methods, which means that every operation on a data type would have to be abstract, which is not very useful. NFR: Ok, I understand this explanation. Please add this explanation as a change to the semantics of DataType in clause 7; maybe include part of 9.1 / 9.2 as an example showing how one can specify a datatype (e.g., Boolean) and .operations. one can perform on that datatype. Issue 14522: OpaqueBehavior::opaqueBehavior should be OpaqueBehavior::language In the sentence: The OpaqueBehavior::opaqueBehavior attribute should instead be .language., consistent with the UML 2.2 specification. You commented .huh?. on the phrase .attribute should instead be .language... By this I simply meant the same thing as in the title of the issue. That the OpaqueBehavior class incorrectly had an attribute called .opaqueBehavior. instead of an attribute called .language.. You didn.t comment on the resolution, so I assume that was OK with you. NFR: Yes. Issue 14523: Items excluded from Kernel You commented: Adding these elements requires more careful attention to what it means for fUML to be a computationally complete subset of the UML. At minimum, we need somewhere a summary of what is that computationally complete subset. Clearly, this subset excludes Package and the import relationships. Adding nested classes is a bit more problematic; what should be te Note sure what you mean. If fUML was computationally complete before, NFR: We have some language somewhere to the effect that we added Package as a way to organize a model but fUML doesn.t add semantics to a package. adding to the subset doesn.t change that. NFR: but now, the computationally complete subset isn.t fUML anymore. It.s fUML - { Package, PackageImport, ElementImport } and I don.t know off the top of my head if anything else needs to be excluded. The items added have only to do with convenience of packaging and naming and don.t affect the semantics at all. NFR: Yes but we have to say that in the spec clearly when we talk about fUML being a computationally complete subset. If not, it.s going to be confusing to say in one place that fUML is computationally complete and in another say that Package doesn.t have execution semantics. Your comment on nested classes is incomplete. But, again, even though this is technically expanding the fUML subset, it does not affect the semantics, since nesting in this case is only a namespace issue. NFR: if you are saying that Class A { class B; } is semantically equivalent to: Class A {}; Class A_B {}; as far as fUML is concerned, then this needs to be said in clause 7 to make it clear that one shouldn.t expect to see any mention of nested classes in clause 8 and that clause 8 assumes that an abstract syntax model with nested classes has been converted into an equivalent model without nested classes using the name replacement above. I don.t know if this information needs to be in clause 2, 6, 7 or 8 but it should be somewhere where we talk about what it means to execute an abstract syntax fUML model. Issue 14524: Incorrect Generalizations in Kernel You commented: Have these changes checked in the reference implementation of fUML? The reference implementation uses Java, which doesn.t support multiple inheritance of classes. So, of course, making these changes won.t allow direct generation of Java classes. But that is irrelevant . a Java implementation restriction should not drive a normative UML-based standard. NFR: How is this not relevant given the fact that the fUML operational semantics is written in a subset of java? The stated intent for the fUML subset is that, when its abstract syntax is merged with the UML L3 abstract syntax, you get UML L3. This is the operational definition of .subset.. The fact is, with the incorrect generalizations, this intent is violated, because the merge would still have the incorrect generalizations not contained in UML L3. This should be corrected, regardless of Java implementation issues. You also commented: This change breaks the operational semantics in clause 8 that depend on the ability to access the Namespace properties of a Type. 8.3.2.2.20 RedefinitionBasedDispatchStrategy::getMethod(return ReturnResult: Behavior, in object: Object, in operation: Operation): Behavior 8.3.2.2.23 StructuredValue::getFeatureValues(return ReturnResult: FeatureValue): FeatureValue 8.6.4.2.5 ReclassifyObjectActionActivation::doAction() This isn.t correct. The only types in fUML are classifiers, and the revision still has classifiers being namespaces (by multiple inheritance). This is the same as full UML . types in general are not namespaces, but classifiers are. NFR: As far as I can tell, these places will make the code for these operations incompatible with the changes proposed due to the missing inheritance. In FUML 1.0 beta1, figure 31 shows that ObjectNode is a specialization of ActivityNode. The composition relationship is shown in red to indicate that it is an idiom used in fUML where multiple inheritance was simplified to single inheritance by replacing secondary generalization relationships with semantically equivalent composition relationships. In this case, inheriting from TypedElement or having a composition relationship to TypedElement achieves the same purpose, specifically, that ObjectNode carries the information that TypedElement provides, i.e., a reference to a type. This resolution would make ObjectNode inherit from both ActivityNode and TypedElement. Is this what is intended here? Yes, the intent is that ObjectNode inherit from both ActivityNode and TypedElement, as in the full UML abstract syntax. Note that there were other instances of the use of red composition in the pre-submission abstract syntax model (such as for the multiple inheritance of TypeElement and MultiplicityElement by StructuralFeature), but these were (properly) replaced with generalizations for the normative abstract syntax. The case of ObjectNode was just missed. NFR: Depending on context, there are 3 relevant versions of fUML. 1) the java-based version for executing the operational semantics. 2) the UML-based version which is structurally a strict subset of UML L3 but unmerged. 3) the UML based version which is merged just like the merged UML L3. I understand that you may feel it is important to describe clause 7 from the perspective of (2), i.e., as a true subset of UML which means multiple inheritance. On the other hand, I really don.t see how this adds value to the spec given that clause 8 is clearly written on the basis of (1), not (2). I would prefer consistency between clause 7 and 8 w.r.t. (1) and if it means that we have to keep the color coding to indicate which composition relationships would be replaced into equivalent generalization relationhsips for fUML in (2), then so be it. -- Ed - Nicolas. --------------------------------------------------------------------------------