more on composition/aggregation

Interesting discussion from those working SysML.

My take is the part/whole debate here is the same one that has been going on in philosophy for thousands of years.

It appears from a modeling standpoint that something disappears when it is no longer of interest in your model.  So if the whole ceases to be in the model, then the parts will also cease to be in the model if I have no interest in the separate parts.  I can see making this explicit in a defined association but I'm concerned about the general understanding of the model if something this fundamental can have a "proprietary" definition.

Ken

Begin forwarded message:

   
FYI, please read the whole email trail

   
    From:    [mailto:] On Behalf Of Branislav   Selic
Sent: Wednesday, January 04, 2006 3:45 PM
To:   
Cc:   
Subject: [SysML-Evaluators] Re:   [sysml-submission-team] [SysML-Evaluators] Re: Clarification request DWO issue   1.00

  

Thanks, David. The debate in the   UML community about white diamond associations is whether they are really   necessary. This is because their dynamic semantics -- as defined in the spec   -- are really no different than that of any "regular" association. That is,   the disappearence of the "container" has no effect on the existence of the   contained elements. The only reason the notion was introduced was to help   modelers identify -- in situations such as you are describing -- which end of   the association represents the "logical container" and which one represents   the "contained" elements. The difference is merely one of connotation, the   containment is a purely conceptual relationship -- just like an automobile is   really a conceptual notion for a collection of parts assembled in a particular   way. From that perspective, it seems ideally suited for your   requirement. 

Regards,   
Bran Selic
IBM Distinguished   Engineer

IBM Rational Software
770 Palladium Drive
Kanata,   Ontario, Canada
K2V 1C8
ph.: (613) 591-7915
fax: (613)   599-3912
e-mail:  

      
"David Oliver"         <> 
Sent by: 
01/04/2006 03:21 PM                   
              
Please respond               to
SysML-Evaluators

                        
              
To
            <>           

              
cc
                      

              
Subject
            [SysML-Evaluators] Re:               [sysml-submission-team] [SysML-Evaluators] Re: Clarification               request DWO issue 1.00

                  
            

Bran and Michael, 
  
If as you say, Bran, the open UML diamond has exactly the   meaning we are seeking, then that is a very simple solution to the need here.   I was under the impression that there was debate within the UML community as   to the exact meaning of the open diamond. It would b e great if that is not   the case anad this provices the solution we need. 
  
david 
----- Original Message ----- 
From:   Branislav   Selic 
To:    
Cc:    
Sent: Wednesday, December 28, 2005 5:16   PM 
Subject: [SysML-Evaluators] Re:   [sysml-submission-team] [SysML-Evaluators] Re: Clarification request DWO issue   1.00 

Thanks, Michael, this is   very good insight. Your arguments seem to me a convincing discourse that the   concept of a whole that you and Dave have in mind is invariably that of a   logical whole; that is, a name given to a collection of parts combined in a   particular way. This whole disappears when the parts are disassembeled   although the parts remain. 

The UML "filled diamond" notion indeed has   different semantics, since it can stay even if the parts are removed while,   when it is removed, the parts are forced to disappear.   

Based on this, I am now convinced   that the capability that you and Dave are seeking is already present in UML.   You can model it simply with any association where the "whole" has a lower   multiplicity bound of 0 (and an upper bound greater than 0) in an association   to the parts. To give it that part-whole connotation, you can use the   "unfilled (white)" diamond notation. This is precisely the intent of the   "unfilled dimaond" notation. 

Cheers, 
Bran Selic
IBM Distinguished Engineer

IBM   Rational Software
770 Palladium Drive
Kanata, Ontario, Canada
K2V   1C8
ph.: (613) 591-7915
fax: (613) 599-3912
e-mail:    

      
"Michael Latta"         <> 
Sent by:          
12/28/2005 04:01 PM         
                  
              
Please respond               to
SysML-Evaluators

        

      
                  
              
To
            <>           

              
cc
                      

              
Subject
            [SysML-Evaluators] Re:               [sysml-submission-team] [SysML-Evaluators] Re: Clarification               request DWO issue 1.00

                  
            

I think one issue   here is the difference in semantics between destruction and   disassembly. 
 
If I disassemble any physical thing I get parts that are distinct   from the conceptual whole.  When I disassemble a software object I might   be left with an object absent its parts.  These are really two very   different types of composition.  In the software case identity is tied to   a "physical" thing that can "own" other things.  In the physical world   only conceptual things have identity and no "physical" thing they are really   tied to.  A car VIN does not really reference the collection of parts   that make up the car, it references the conceptual thing that is the car.    Each of the collection of parts might also have its identity and so on.    In software the model is very different.  A block of memory has an   identity (address, OOP, what ever).  You could talk about software   identity as being to the collection of properties that are each like physical   things, but that is not how UML or most OOP languages work.  The identity   of an object references the logical object and the collection of slots called   properties in UML.  Where those properties are value types the slot takes   up enough room for the value type, where it is a reference type then the space   taken is only for the reference.  But, a "car" object takes no space   beyond the space of its parts, and does not take any space if the parts are   not present. 
 
In both cases if I destroy an object the parts that make up that   object are also destroyed.  The process of destruction may vary between   physical systems, software, and even between different software systems.    If the software object is in a database the steps required to "destroy"   it are quite different than if it is in a programming language with a garbage   collector. 
 
 

    From:    [mailto:] On Behalf Of Branislav   Selic
Sent: Wednesday, December 28, 2005 11:58 AM
To:   
Cc:   
Subject: [SysML-Evaluators] Re:   [sysml-submission-team] [SysML-Evaluators] Re: Clarification request DWO issue   1.00

Well,   since we are on the point of distinguishing between "logical" and "physical"   things (the latter defined as being stuff of energy/matter), I can see some   problems distinguishing these two categories. When does something stop being   "logical" and becomes "physical"? Is a "car engine" a physical or logical   entity? It can be argued quite convincingly that it is a logical concept,   since it is just a name for a collection of distinct physical parts that make   up the engine (block, cylinders, camshafts, etc.) -- each of which, of course,   can itself be viewed as a logical collection of parts, etc. As everyone knows,   this argument can be carried on "ad absurdum" (atoms, quarks, etc.), but it   seems rather patent that there is no single point in this progression where   the qualitative distinction occurs. It seems to be a matter of choice made by   the modeler as to where to draw the line. 

Cheers,   
Bran 

      
"Michael Latta"         <> 
Sent by:          
12/28/2005 11:59 AM         
                  
              
Please respond               to
SysML-Evaluators

      
                  
              
To
            <>           

              
cc
                      

              
Subject
            [sysml-submission-team] [SysML-Evaluators] Re:               Clarification request DWO issue         1.00

                  
            

James, 

I am sure that David did not mean to imply that SysML   can only model physical systems.  It is I am sure just his focus for this   point.  You make a good point about the link being a part of the physical   system and it being dependent on environmental conditions, but I would not   have chosen to model it that way.  I might have a "logical" component   that is the wireless system which is decomposed into a transmitter, a   connection, and a receiver.  Then allocate the behavior to the two   physical parts.  The behavior of the transmitter and receiver will need   to deal with a loss of connectivity, but it is not really a component of the   system that disappears.  The logical component still exists, as do the   physical parts, they just lose connectivity.  Conservation of mass is not   subject to modeling whim.  On the other hand software components can be   destroyed at will since they do not have mass to conserve.  It would   still be useful to be able to distinguish the cases where a software component   contains other components from the case where it is constructed from other   components.  In the later case if you remove all the contributing   components there is no software left (as in a logical package), while in the   first case there may still be residue (as in a class enclosing other   classes). 

Michael 

    From:    [mailto:] On Behalf Of James N   Martin
Sent: Wednesday, December 28, 2005 7:04 AM
To:   
Subject: [SysML-Evaluators] Re:   Clarification request DWO issue 1.00

David, 

I am surprised to hear that system elements do not disappear.   You must be thinking of purely physical systems. Is there anything in the   SysML spec that says that the systems to be engineered must be physical only?    If this is the case, then it needs to be made very explicit in the   description of SysML and its intended use that it is designed for physical   systems only. 

There are many system elements that can disappear.  A role   can come and go depending on the need for that role. A role can be a system   element.  A wireless communication link can disappear when the medium   through which it is meant to traverse goes away (eg, when line of sight is   lost between transmitter and receiver). This comm link is a system element. A   person who performs a system function can disappear (eg, go home sick) and the   personnel function can cease to be performed.  Here are but a few   examples even for a physical system where the component "disappears".  I   was not aware that SysML would prevent me from modeling such   systems. 

Regards,
James 

      
"David Oliver"         <> 
Sent by:          
12/28/2005 06:46 AM         
                  
              
Please respond               to


        

      
                  
              
To
            <>           

              
cc
                      

              
Subject
            [SysML-Evaluators] Re:               Clarification request DWO issue         1.00

                  
            

Bran, 

Thanks for your   observations. 

There   is a difference to note to you. In the constructs we use there is no concept   of disappear because this violates conservation of mass and does not happen in   the physical world. We can transform things but neither create them from   nothing or make them disappear. We can put them together and take them apart.   We are modeling what happens. If the whole is taken apart, the parts remain.   If all the parts are removed from the whole, there is no whole left. This is   what happens in the manufacture, maintenance and disposal life cycle phases.   It is what happens when i build with blocks with my grandchildren. 

I suspect it takes profile to   produce this construct and do not believe that should be excessively   difficult. It should have its own distinct symbol.   

David 
-----   Original Message ----- 
From: Branislav   Selic 
To:    
Cc:  
Sent: Monday, December 26, 2005 5:57 PM 
Subject:   [SysML-Evaluators] Re: Clarification request DWO issue 1.00 

Dave Oliver wrote on 12/26/2005 10:35:25   AM:

> The black diamond of UML is a construct like these and does   not 
> represent the essential "built from" construct. There is no   concept 
> and sympol for "built from" in UML. The black diamond means   only 
> "contains a". It has definitions that are questionable for   physical 
> reality such as the notion of deleting the whole and the   aprts 
> listed are deleted. 

However, there is nothing to prevent a profile builder to   define a specialization of UML's "filled diamond" that adds further   constraints over and above those defined for standard UML. If I understand   Dave's explanation correctly, the UML semantics are fully in line with the   desired "built from" semantics (the parts disappear if the whole disappears),   it is just that they are insufficient. 

If for some reason the "filled diamond" semantics are   inappropriate, then there is nothing to prevent the definition of a different   association stereotype that has the desired semantics. For example, the   "unfilled diamond" might be a good choice for this. 

> In the   systems engineering world here is an entire life cycle phase 
> that is   missing in the software world. It is called Disposal. 

Having spent   many years working on start up and take down problems in large telecom   systems, I strongly disagree with the statement that such problems do not   exist in the software world. For example, doing a clean-up of a system   software following a failure -- so that it can be restarted with minimum   disruption is a major issue in fault-tolerant high-availability   systems. 

>   Question 2. 
>     
> It is true   that completeness can only be specified with regaard to 
> the context   within which it is expressed. However, that fact is 
> irrelevant to the   essential need for the language to have a 
> representation for complete   decomposition. Otherwise no analysis for
> performance can be done. The   initial level of fidelidy in analysis 
> will likely be less than that   later in the program. Completeness 
> does have a context as do all of   the other modeling views used in enginering.   

Interesting. I see "completeness" as a   statement ABOUT a model not a statement WITHIN the model itself. As Dave says,   the question has to be posed in a broader context which, by definition,   extends beyond the viewpoint of any given model (because all models are, again   by definition, partial and based on viewpoints). Fortunately, it is something   that can be attached to the model easily.   

Cheers...Bran   

 

 
------------------------------------------------------------------------------------------
 
Ken Laskey
 
MITRE Corporation, M/S H305     phone:  703-983-7934
 
7515 Colshire Drive                        fax:        703-983-1379
 
McLean VA 22102-7508
  

smime.p7s