Issue 17390: Migrate UML::Component's ability to own UML::PackageableElements to UML::Class (uml2-rtf)
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity: 
Summary: UML2.4.1 Superstructure, section 8.3, Figure 8.4 shows that UML::Component has a composite association to UML::PackageElement; that is:


UML::Component::packagedElement : UML::PackageableElement { subsets UML::Namespace::ownedMember }


This is the only place in the UML metamodel where a kind of UML::Classifier has the capability to own arbitrary kinds of UML::PackageableElements.


As long as the classifier capabilities needed in practice are within the scope of what UML::Class already provides, then it is practically very useful to use UML::Component in lieu of UML::Class.
By doing so, a UML::Component-as-an-enhanced-UML::Class gains the capability to own additional kinds of UML::PackageElements that a plain UML::Class cannot; e.g.:


UML::Package, UML::Dependency, UML::InformationFlow, UML::ValueSpecification, UML::InstanceSpecification, UML::Event, UML::Observation, UML::Profile, UML::Model.


Unfortunately,  other kinds of UML::Class do not get such benefits. For example, a UML::StateMachine is a kind of UML::Class just like UML::Component but unlike UML::Component, it can't own arbitrary UML::PackageableElements.
In particular, it cannot own any UML::Event even though this would make eminent sense in some cases (e.g., internal events not visible outside of the UML::StateMachine).


Finally, the well-formedness and semantics of a kind of UML::Class with namespace-nested UML::PackageableElements need to be addressed for unusual combinations including but not necessarily limited to the following cases:


1) nested UML::Profiles and UML::ProfileApplications
2) specialization of a general classifier nested within its packagedElements
3) applying a stereotype defined in a UML::Profile nested within its packagedElements
4) the target of an elementImport from a UML::Namespace nested within its packagedElements

Resolution: 

Revised Text: 
Actions taken:
May 22, 2012: received issue
Discussion: 

End of Annotations:=====

m: "Rouquette, Nicolas F (313K)" <nicolas.f.rouquette@jpl.nasa.gov>
To: "issues@omg.org" <issues@omg.org>
CC: "uml-spec-simplification@omg.org" <uml-spec-simplification@omg.org>
Subject: Migrate UML::Component's ability to own UML::PackageableElements to
 UML::Class
Thread-Topic: Migrate UML::Component's ability to own
 UML::PackageableElements to UML::Class
Thread-Index: AQHNOExtUdwzQMMzXUy0mfAXCIsbvA==
Date: Tue, 22 May 2012 18:55:24 +0000
Accept-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [128.149.137.114]
X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov
X-AUTH: Authorized


UML2.4.1 Superstructure, section 8.3, Figure 8.4 shows that UML::Component has a composite association to UML::PackageElement; that is:


UML::Component::packagedElement : UML::PackageableElement { subsets UML::Namespace::ownedMember }


This is the only place in the UML metamodel where a kind of UML::Classifier has the capability to own arbitrary kinds of UML::PackageableElements.


As long as the classifier capabilities needed in practice are within the scope of what UML::Class already provides, then it is practically very useful to use UML::Component in lieu of UML::Class.
By doing so, a UML::Component-as-an-enhanced-UML::Class gains the capability to own additional kinds of UML::PackageElements that a plain UML::Class cannot; e.g.:


UML::Package, UML::Dependency, UML::InformationFlow, UML::ValueSpecification, UML::InstanceSpecification, UML::Event, UML::Observation, UML::Profile, UML::Model.


Unfortunately,  other kinds of UML::Class do not get such benefits. For example, a UML::StateMachine is a kind of UML::Class just like UML::Component but unlike UML::Component, it can't own arbitrary UML::PackageableElements.
In particular, it cannot own any UML::Event even though this would make eminent sense in some cases (e.g., internal events not visible outside of the UML::StateMachine).


Finally, the well-formedness and semantics of a kind of UML::Class with namespace-nested UML::PackageableElements need to be addressed for unusual combinations including but not necessarily limited to the following cases:


1) nested UML::Profiles and UML::ProfileApplications
2) specialization of a general classifier nested within its packagedElements
3) applying a stereotype defined in a UML::Profile nested within its packagedElements
4) the target of an elementImport from a UML::Namespace nested within its packagedElements
Nicolas.