| 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
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: bselic@ca.ibm.com
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: SysML-Evaluators@googlegroups.com
Cc: SysML-Evaluators@googlegroups.com
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: bselic@ca.ibm.com
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: SysML-Evaluators@googlegroups.com [mailto:SysML-Evaluators@googlegroups.com] On Behalf Of Branislav Selic
Sent: Wednesday, December 28, 2005 11:58 AM
To: SysML-Evaluators@googlegroups.com
Cc: SysML-Evaluators@googlegroups.com
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
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: SysML-Evaluators@googlegroups.com [mailto:SysML-Evaluators@googlegroups.com] On Behalf Of James N Martin
Sent: Wednesday, December 28, 2005 7:04 AM
To: SysML-Evaluators@googlegroups.com
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
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: SysML-Evaluators@googlegroups.com
Cc: SysML-Evaluators@googlegroups.com
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 |