[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] more on composition/aggregation
Personally, I find the 'lifetime' conceptualization less than helpful (if the parent disappears then black diamond components disappear but not white diamonds) I think a better way of thinking might be about integrity: does the end of the black diamond association have any meaning without the parent? For example, the 'interior space' in a car has no meaning outside the context of a car. But a wheel of a car does. Frank On Oct 4, 2007, at 10:29 AM, Ken Laskey wrote: > 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: SysML-Evaluators@googlegroups.com [mailto:SysML- >> Evaluators@googlegroups.com] On Behalf Of Branislav Selic >> Sent: Wednesday, January 04, 2006 3:45 PM >> 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 >> >> >> 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 >> >> >> "David Oliver" <DOLIVER81@tampabay.rr.com> >> Sent by: SysML-Evaluators@googlegroups.com >> 01/04/2006 03:21 PM >> Please respond to >> SysML-Evaluators >> >> >> To >> <SysML-Evaluators@googlegroups.com> >> 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: 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 >> >> "Michael Latta" <lattam@mac.com> >> Sent by: SysML-Evaluators@googlegroups.com >> 12/28/2005 04:01 PM >> Please respond to >> SysML-Evaluators >> >> >> >> To >> <SysML-Evaluators@googlegroups.com> >> 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: 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 >> >> "Michael Latta" <lattam@mac.com> >> Sent by: SysML-Evaluators@googlegroups.com >> 12/28/2005 11:59 AM >> Please respond to >> SysML-Evaluators >> >> >> >> To >> <SysML-Evaluators@googlegroups.com> >> 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: 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 >> >> "David Oliver" <DOLIVER81@tampabay.rr.com> >> Sent by: SysML-Evaluators@googlegroups.com >> 12/28/2005 06:46 AM >> Please respond to >> SysML-Evaluators@googlegroups.com >> >> >> >> To >> <SysML-Evaluators@googlegroups.com> >> 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: 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]