Be Advised: Classified, FOUO, and PII Content is Not Permitted

  • Replies 6 replies
  • Subscribers 462 subscribers
  • Views 14801 views
  • Users 0 members are here
Related

Question about Nested Parts

Chandan Mathur

Hello All, first time posting here.  

I've attempted to attach an image, but not sure if it worked.

I'm using Cameo v19, SP4 and SysML

A very simple BDD

  1. Door block composed of a Window block
  2. A Car block with two compositions to the Door block named door1 and door2.  Two compositions so I can refer to each Door part individually.
  3. I create an IBD for Car and display the two Door parts, door1 and door2.
  4. I then display the parts within door1 and door2
  5. As expected, i see a Window part in each Door part
  6. But, unexpectedly, the Window part is the same model object for both Door parts.  It has the same element ID.  I would have expected to see a different Window parts for each Door.

How should i structure my BDD so that each Door has its own, unique Window part?

thank you, 

Chandan

 

 

Parents
  • 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
  • in reply to Geoffrey Shuebrook
    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.
Reply
  • in reply to Geoffrey Shuebrook
    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.
Children