Question about Nested Parts

Chandon,

You have defined only 1 definition of «block» Door and «block» Window in your model. The «block» Door has a single Usage of the «block» Window as a part property. No matter how many usages (aka: Composite Association) of the «block» Door the «block» Car has, the Window usage by the Door is always the same part property. “Usage” as a part property, is in essence, an “instance” of the “Definition” of the Block which defines the part property.

The semantics of this model asserts that the «block» Door ALWAYS has the same properties. If that is not true, then you need to create unique definitions of Door and Window in the model.

I’d like to suggest 2 papers by Conrad Bock that may more completely illuminate this issue for you.

1) UML 2 Composition Model &
2) Componentization in the Systems Modeling Language

Regards,
Geoff

Geoff is correct. I don't often use instances...and if the doors are really different (LH/RH, for example), you should make a LH Door and RH Door block (with LH and RH Windows, respectively). It depends upon how you want to structure your model.
I'd also ask you to consider what you're trying to do...I find BDDs are often misused to show things that are better represented in a table, matrix, or relation map...or IBD, for that matter.
Focus on getting the containment tree (model) right and the rest will flow naturally!

Chandon,

I’d like to follow-up on Michael’s and my post from yesterday. It is not my objective to be critical of your effort, but to share a perspective or two.

Every UML modeling tool that I have used makes use of diagrams to create model content. That said, a diagram is NOT a model. A diagram is simply a view of the elements of the model. Michael’s post alludes to this construct when he states “Focus on getting the containment tree (model) right and the rest will flow naturally!”. We could populate the "containment tree" without using diagrams, this is an uncommon practice by most. Which is not to say that it is wrong to employ diagrams when populating the model. Using diagrams is just the typical practice and one of the reasons that many models are merely collections of diagrams and not optimal models of the referent in the context of the model's intended use.

Your model of a car, a real-world object, has some intended purpose and user. As the modeler you have decided that the model should reflect less abstraction in regard to the car’s doors, by representing the properties of each of the car's doors uniquely. As Michael has stated, to accomplish that goal you need to create 2 unique model elements, blocks, one for each door. If the parts of each door are unique to the definition of each unique door, then they too must have unique definitions. Each unique door having their own unique window definition. That said, why do you feel the need to create such specificity in this model? This effort must be justified, by some return on the investment, by the purpose of the model in the context of its use.

If the specificity of the car’s doors serves no purpose in this particular model, then don’t invest the modeling effort. If the only relevant fact about the car’s doors is that there are 2 of them, them simply represent that fact using a multiplicity of “2” on the door end of the Car to door relationship. Don't create 2 part properties for the car doors.

Another consideration I would like to share. You have chosen to name the door part properties by “door1” & “door2”. Do these names express the role/responsibility of each door in the context of the car? Would it be useful to the user of the model to have this understanding of the car’s description? Might there be names that would effectively convey this information?

Thank You for the opportunity to share my perspectives.

Geoff

Geoff: Thanks for elaborating; agree that you need to understand the use of the model. For example, if you're modeling a laptop, is it enough to say that it has 4 USB ports or do you need to label them Left Front, Left Rear, Rear, and Right? For the record, I usually DON'T use multiplicities because I usually want individual ports to connect (makes it easier to see when you've used all 4 connections up, for example)...but on occasion I do (If I'm modeling a tank with 8 road wheels per sides, is there any value in showing 16 separate wheels? it depends). As Geoff says, understanding the long-term use/need should inform your modeling from the start.

Geoff and Michael, thank you very much for your perspectives. These are very valuable. My intended use was to be able to create a bill of materials (BOM) in a model and was trying to better understand the meaning of composition. Geoff, I'll definitely look at those papers, though it appears they are behind a paywall.

thanks again for taking the time to respond.

Conrad makes most of his papers available on his website < m.conradbock.org/bockonline.html >