Issue 14943: Provide notational mechanism to represent any group of model elements based on some criteria w/o stealing ownership (uml2-rtf) Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com) Nature: Uncategorized Issue Severity: Summary: Non-structural, non-owning Containment While packages and stereotypes have their purposes, we need another way of combining and identifying groups of related elements based on specific partitioning criteria. This allows us to categorize and organize system elements – a common task for SEs. We could use this to identify those elements that are related to a particular architectural layer, due in a particular delivery, produced by a particular manufacturer, or related to a particular concern (e.g., security). Model elements could belong to any number of these containers. These containers should appear on diagrams, tables, and the browsers, but should not confer or change any prior ownership. Populating these containers could be done mechanically and/or by execution of rules. The containers can have value properties and dependencies that are considered to logically apply to the members of the container Resolution: Revised Text: Actions taken: January 11, 2010: received issue Discussion: End of Annotations:===== te: Mon, 11 Jan 2010 00:30:06 -0500 From: "Chonoles, Michael J" Subject: OMG: Provide notational mechanism to represent any group of model elements based on some criteria without stealing ownership To: "issues@omg.org" Thread-Topic: OMG: Provide notational mechanism to represent any group of model elements based on some criteria without stealing ownership Thread-Index: AcqSfyGO4eLl6XDfQAGEwi76RtHI5A== Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Non-structural, non-owning Containment While packages and stereotypes have their purposes, we need another way of combining and identifying groups of related elements based on specific partitioning criteria. This allows us to categorize and organize system elements . a common task for SEs. We could use this to identify those elements that are related to a particular architectural layer, due in a particular delivery, produced by a particular manufacturer, or related to a particular concern (e.g., security). Model elements could belong to any number of these containers. These containers should appear on diagrams, tables, and the browsers, but should not confer or change any prior ownership. Populating these containers could be done mechanically and/or by execution of rules. The containers can have value properties and dependencies that are considered to logically apply to the members of the container Michael Jesse Chonoles LMCO / OMG SE-DSIG