Issue 6246: fig 141 p205 and 7.13.2 p101 / just what sort of relationship is <<merge> Question about InterruptibleActivityRegion () Source: Capability Measurement (Mr. Karl Frank, Karl.Frank@ngc.com karl.frank@ngc.com karl.karolus@gmail.com karl.frank@capabilitymeasurement.com) Nature: Uncategorized Issue Severity: Significant Summary: medium significance The text for Figure 141 says "The package dependencies of the Actions chapter are shown in Figure 141." Then the diagram shows IntermediateActivities packages as dependent on StructuredActivities. This conflicts with the text for fig 141, the text of section 12.1 page 265 says "The Intermediate and structured levels are orthogonal. Either can be used without the other or both can be used to support modeling that includes both concurrency and structured control constructs." This statement implies that there is NO dependency between StructuredActivities and IntermediateActivities, none in either direction. Yet the Figure 175 says otherwise Suggested resolution: The root of this problem may be: a. Merge is intuitively a symmetrical relationship, whereas it is defined in UML2 as directed. b. In 7.13.1 on p 99, the description of the fundamental modeling element Package says "...a package can be merged with other packages." It is noteworthy that only one other package-to-package relationship was thought important enough to call out in the text introducing Package, and that is the containment ownership of nested packages. This prominence suggests that the meaning of 7.13.1 "... a package can be merged with other packages" is that "Any package can be merged wih any other package." or more exactly, a PackageMerge is valid between any two packages, without restriction. c. Merge is defined in a way that makes it appear to be a dynamic function that takes two packages and produces a new package which is not the same as either of the two. This means it is not a relationship, but some kind of meta-operation, a very interesting but hairy concept. Resolution: Revised Text: Actions taken: September 10, 2003: received issue March 9, 2005: closed issue Discussion: The author of the issue seems to have misread the spec. Figure 141 shows a dependency from IntermediateActions (not IntermediateActivities) to StructuredActivities. However, there was indeed a merge in the original FAS that coupled the Intermediate and Structured Activities, but this link was removed in response to issue 6179. Therefore, even that is no longer a problem and the statement about the separation of these two types of activities is valid. As for the recommended solution related to package merge, that issue is dealt with as part of the resolution to issue 6279. Disposition: Closed, no change End of Annotations:===== ender: juergen@amethyst.omg.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Sep 2003 16:26:50 -0400 To: uml2-superstructure-ftf@omg.org From: Juergen Boldt Subject: Fwd: UML2 super/fig 141 p205 and 7.13.2 p101 / just what sort of relationship is <>? X-Sender: juergen@amethyst.omg.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Sep 2003 16:20:17 -0400 To: juergen@omg.org From: Juergen Boldt Subject: Fwd: UML2 super/fig 141 p205 and 7.13.2 p101 / just what sort of relationship is <>? Subject: UML2 super/fig 141 p205 and 7.13.2 p101 dependent or orthoganol? Date: Wed, 3 Sep 2003 21:08:24 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML2 super/fig 141 p205 and 7.13.2 p101 / just what sort of relationship is <>? Thread-Index: AcNygQChx3DXwkE7RH2t139GCBJzUQ== From: "Karl Frank" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h8417Ke4009079 medium significance The text for Figure 141 says "The package dependencies of the Actions chapter are shown in Figure 141." Then the diagram shows IntermediateActivities packages as dependent on StructuredActivities. This conflicts with the text for fig 141, the text of section 12.1 page 265 says "The Intermediate and structured levels are orthogonal. Either can be used without the other or both can be used to support modeling that includes both concurrency and structured control constructs." This statement implies that there is NO dependency between StructuredActivities and IntermediateActivities, none in either direction. Yet the Figure 175 says otherwise Suggested resolution: The root of this problem may be: a. Merge is intuitively a symmetrical relationship, whereas it is defined in UML2 as directed. b. In 7.13.1 on p 99, the description of the fundamental modeling element Package says "...a package can be merged with other packages." It is noteworthy that only one other package-to-package relationship was thought important enough to call out in the text introducing Package, and that is the containment ownership of nested packages. This prominence suggests that the meaning of 7.13.1 "... a package can be merged with other packages" is that "Any package can be merged wih any other package." or more exactly, a PackageMerge is valid between any two packages, without restriction. c. Merge is defined in a way that makes it appear to be a dynamic function that takes two packages and produces a new package which is not the same as either of the two. This means it is not a relationship, but some kind of meta-operation, a very interesting but hairy concept. ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org From: Edwin Seidewitz To: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Subject: RE: ,gi, issue no-number [actually, Issue 6246 is relevant] -- Pa ckage Merge--two naming problems Date: Wed, 15 Oct 2003 12:11:09 -0400 X-Mailer: Internet Mail Service (5.5.2655.55) > > 2. The proposal to always merge into a top package. This has the > unintended result of removing the ability to use the standard naming > mechanism to distinguish the different metamodel classes with > unqualified > names that are the same. > > I hope this problem can be fixed, but i don't see how. One way to fix this would be to explicitly name the result of the "merge" transformation. That is, rather than identifying a merge transformation by a dependency between fragment A and base B with the "merged" package also being called B (or is it A?), we should have an explicit package C which merges the fragment A into the base B, so we get a new namespace. Karl's first presentation had a diagram that as much as showed this (though I don't think Karl was necessarily proposing this as an actual notation, and neither am I). In some ways, this is closer to how package merge is used in the current spec, with a number of packages merged together into a new namespace. However, the semantics of the result C, as I am suggesting it, would be in terms of the transformational conception of merge that Karl describes, not the specialization-based approach in the current spec. Also, in the current spec, the package being "merged into" includes a model fragment that provides the skeleton for the merge, while I would suggest that the result C should be entirely the result of the transformation. This approach is basically a structured "mix in" approach. We would have a hierarchy of base packages that are related by normal dependencies. Then we would have a separate set of "mix in" packages (which should have minimal or no dependencies on each other) that could be combined with base packages using package merge. I would, lastly, suggest that the packages resulting from the merges could be the basis for a reasonable number of explicit compliance points. -- Ed ================================