From earlier
Don't know whether I agree with the fine print there pardner!
Well, bruce, I wasn't as clear as I should have been in my choice of words. In the "fine print" - which quoting doesn't copy - I meant
can as in
is able to not as in
must(IMO) All UML composition says is that the part cannot exist without the owning element**. Who or what does the immolating is not specifically mentioned. Again, they've left that small detail up to the implementers.
Actually, I got the opposite impression: in composition there is a structural and/or functional relationship between the whole and the part such that if you take away sufficient parts, you no longer have the whole. Or that the part does not exist without the context of the whole.
I agree with you that the immolation thing has got in the way of correctly understanding what's going on. However, given my definition above, if you have one of my compositions, it must be the case that if the whole is destroyed, the parts (at the time) must also be destroyed. I'm not saying the whole destroys them necessarily, but they are gone none the less. (However, see later)
The possible corollaries are, as you say undefined in terms of meronymistocity (whatever). Can the whole exist without the part - according to OMG yes. Destruction of the whole implies destruction of the parts, but the responsibility thereto is not specified.
Meronymy, meronymy, meronymy
Yes, the whole can exist without the part! That's one of the tests for simple aggregation. I can have a team with no players. I can have an empty collection. I certainly don't have a composition. I don't even have a container!
I'll go even further. The "whole" is in fact the (super)sum of the parent (the owning element) and the parts. There is a boatload of implications and bad assumptions created because the name of the whole is usually applied to the owning element and not to the real whole.
Ah.. Here it depends on the relationship between the whole and the part... If the whole is an collection or a container, then the name
does only apply to the whole and not to the part. On the other hand if you have a composition like I defined above then your assertion is indeed correct! To be a bicycle, I need to have two and only two wheels. Each wheel is not the bicycle and the bicycle is more than the two wheels. Take one wheel away, and I have either a broken bicycle or a unicycle! Add a third wheel and I have a tricycle.
So to go back to ** above, existence of the part does not necessarily depend on existence of the owning element, but as you say, on existence of the whole.
See how I've turned it right around? The crucial test, for me, is can the whole exist without the parts? ..And which parts. I think we can say that when we have composition, we can declare some canonical set of parts that constitute the whole and other parts that merely adorn or enhance the whole. Thus in the bicycle example, it may have handle bars, but they aren't essential to it being a bicycle.
Going even further! The presumption that an owned object ceases to exist on the demise of the owner is a bit restrictive. The truth is, the characteristics of the part that are evinced through its participation in the whole may cease to exist but oftentimes the part remains - albeit usually in a new role.
Now you come to the crux of the question - and again it's about the relationship. Take a room in a house, without rooms, you can't have a house. However, if you take the house away, you don't have rooms. But some rooms (like demountables) can be added to a house and taken away from the house. What's going on here? In my view, it's about what happens at the time of destruction. If the wheel is on the bicycle when I destroy the bicycle, then the wheel is also destroyed. If it's not it isn't. That's why it warrants the filled diamond.
Class Frog::iAmphibian {
frogbit[2] Legs;
frogbit[..] Otherbits;
public Legs Frog.ChopUp();
}
There are zillions of lines of code being written today just to cope with this type of excision. Don't believe me?
Order<*>--OrderLineItem
Invoice<*>--InvoiceLineItem
Receipt<*>--AllocationLineItem
Stock<*>--InventoryItem
.....
These xxItems are all just the same froglegs, but how many lines of creates, moves and copies are being written to cope.
These depend on how they are defined and modelled. If you define the Order as the (super)sum of the common Order Header data and the set of Order Line Items, but require that an order must have at least one line item, then the order can't be persisted without a line item. Here you have a composition. If you consider it like a collection and allow empty orders (for whatever reason) then you have modelled it as an aggregation. Certainly, an Order Item can't exist on its own since it automatically creates a new order (That is, an order item is always part of an order even if it is the only item on that order.) Since this is part of the business model, each enterprise has a degree of control as to how it wishes to represent all of these order cycle concepts. However, just for a minute going back to my world vs business vs system model, my advice would (and has been), if you also require that the order be a contract to supply, then contract law (in most jurisdictions) requires that there be a good to supply for some consideration and thus composition is better than aggregation.
Thus when I have removed the last Order Item, I have destroyed the Order. If I destroy the Order, I must destroy all the Order Items currently comprised - since they have no life on their own! If I wish to save an Item, I must excise it from the order to be destroyed first.
Note, although we colloquially say the team died in the air crash, what actually happened is ALL the current members of the team died in the air crash. The team is dead, long live the team...
Anyway its all behavioural and shouldn't be in a structure model.
bruce
Well, I hope I've shown it is more than just behavioural... (Although I agree with you that there are a whole lot of behavioural consequences to the use of the right form of meronymy). I'm not agreeing with mikewhit that object life cycle is a special form of behaviour. I'm saying that the notion of composition is inherent in the definition of the whole (regardless of life cycle).
Meronymously...
Paolo
