What would you consider to be a good abstraction of the Part_of Meronymy?
This question arises out of a desire to have code generators produce outputs that are enriched by the meronymic attributes specified in a UML model and to more clearly express the realization goals of the software development process (as communicated by a software engineer to a programmer). That is, once I stereotype an association as a <<Part_of>>, and having published the conclusions from this discussion, what may I reasonably expect a programmer to code in response to that specification; and, what additional policy information do I need to communicate in, perhaps, another communication medium.
This discussion thread has been forked from a discussion on
Collections Containers, Composites and Nests and conclusions drawn here can be brought back to the parent discussion.
Background InformationMeronimies Meronimies describe the part-whole (a.k.a., Has-a) relation. It is a fairly complex relation which attempts to take into account the degree of differentiation of the parts with respect to the whole and also the role that these parts play with respect to their whole. For example, elements such as spatial cohesion and spatial differentiation, functional differentiation and nature of the links between the parts are crucial elements for determining meronomies. In fact, depending on the quality of these elements, we may have different kinds of meronomies, with different types of properties.
The meronomy relation has itself some properties (or attributes) which must be taken into account in any realistic model:
• optionality of a part,
• cardinality of a part with respect to the whole, e.g. a human has 2 legs, a car has 4 wheels,
There are 6 kinds of meronomies which differ according the functionalities, the spatial cohesion and the degree of dissimilarity between the parts and their whole. In this thread, we are discussing the
Part_of meronymy I'll be setting up similar discussions for the other 5 meronymyies.
PoliciesSome aspects of the following attributes and behaviors may be controlled by the adoption of various policy directions and their accompanying policy variant implementation. For example, it can be a policy decision as to whether an item may self-remove from a collection or grouping. The policy would be entitled: Item self-removal. The two implementations would be: Item can self-remove and the other Item cannot self-remove. As each instance of the whole is created, the appropriate policy implementations are applied and the behavior adjusted accordingly.
Where a behavior may be policy controlled the denotation [Policy] is added. Policies allow for differences in the nature of the domain being modeled. See:
sargassoNow to the Abstraction...A work in progress.
Composite / integral PartThe Part_of meronymy describes a relation between a composite and its parts. A Composite is a structure or an entity made up of distinct components. In this context, Composite is similar to, but shouldn’t be constrained to the UML 2 definition of a composite. Here,
composite is a higher level abstraction that also includes the concepts of UML 2 composites with inner structures, separately deployable components (as in J2EE or *.NET), browsers and the like.
• There is a clear structural and functional relation between the composite and its parts and possibly between the parts themselves, e.g. handle/cup, engine/wheel, etc. [Policy}
• The Parts are generally not of the same type as the Composite.
• When the Parts are of the same type as the Composite, there is a potential for recursion. [Policy]
• Instances of Parts can only be in one Composite instance at a time.
• Parts may need to know which composite object they are in. [Policy]
• Parts may collaborate with each other to effect the overall behavior of the Composite. [Policy]
• Some Parts are intrinsically part of the composite; others are extrinsically in the relationship for adornment. [Policy]
• If the part is intrinsic to the composite, the multiplicity of the component must be equal to or greater than 1.
• Destruction of the composite destroys the instances of its parts. [Policy]
• An integral part is not necessarily an intrinsic part.
• Destruction or modification of an intrinsic part always destroys the composite.
Question: If the vocal chords of a goose (the part) are transplanted into a duck (the composite) so that the duck now ‘honks’ instead of ‘quacking’, has the duck been sufficiently modified to be considered destroyed?
• Destruction of an extrinsic part does not destroy the Composite. [Policy]
• Composite objects define the types of the intrinsic parts.
• Any given part may, or may not, be dereferenced through an attribute containing the referencing information. [Policy]
• Components may have their parts ‘wired in’ at instantiation or execution time. For example: under Inversion of Control (IoC), components my be given their part references via constructor and/or setter methods. [Policy}
• A Composite may, or may not,
own its parts; but it does have exclusive stewardship responsibilities for, and usage rights to, the parts while they participate in the association. [Policy]
Notation: An Association stereotyped as <<partOf>>. Association ends may be adorned with navigation arrowheads, cardinallity and
Ownership Diamonds. An optional link name (formed by the conjunction of two verbs, or verb phrases, separated by a slash) assists the reader in verbalizing the association from either of its ends. Serious consideration should be given to the use of an Association Class to provide information about, and methods to manage, the nature of the association.
And back to the question...This thread is a Request For Comments (RFC). I would like to hear your thoughts on this abstraction of the Part_of meronymy. Is it valid? Are parts of it invalid or missing? Do you have a contribution to make? Feel like pontificating?
What??
