-
Key: UML22-356
-
Legacy Issue Number: 11657
-
Status: closed
-
Source: Adaptive ( Mr. Pete Rivett)
-
Summary:
Section 13.1.6, figure 13.11 (of Infra) and 18.2.7, figure 18.11 (of Super) show an example of a profile containing Types which are available for use when the profile is applied. This rests on the statement “(since profile application is a kind of import)”. However this is not the case: ProfileApplication only inherits from DirectedRelationship.
To achieve the end effect of the example there seem to be two alternatives:
a) Alter the metamodel to make ProfileApplication inherit from PackageImport, with appropriate redefinitions.
b) Explicitly state that ProfileApplication has exactly the same semantics as PackageImport without inheriting from it. More awkward but lower impact. And will mean that generic processing that works off Imports will not pick up ProfileApplications.
This area is causing significant consternation for groups such as UPDM trying to define sophisticated profiles that make use of common elements or other profiles.
-
Reported: UML 2.1.2 — Tue, 20 Nov 2007 05:00 GMT
-
Disposition: Resolved — UML 2.2
-
Disposition Summary:
ProfileApplication makes stereotype names visible to the referenced metamodel, not the model the profile is applied to. ProfileApplication is not a kind of PackageImport because of this crossing of metamodel levels. As with package import, profile application does not expose the names of nested profiles. Therefore alternative b) is the appropriate choice.
-
Updated: Fri, 6 Mar 2015 20:58 GMT