Clarification request DWO issue 1.00

[Erik Herzog]

David, All,

 

In issue 1.00 in the attachment David Oliver argues for the inclusion of a specific element to capture Decomposition into all parts.

 

While the issue as captured is clear it leads to a number of questions:

 

1. David writes “The decomposition into all of the parts means “built from” in the sense that if you take away all of the parts shown below the whole, then there is nothing left”. While this is true for realised systems it is not true for top down architecting of a system. I tend to identify system components in a top down approach rather than a bottom up one. In other words I identify the components before identifying their parts. Clearly it can’t be in the interest of SysML to prohibit this development approach? (Top down development is described in most SE literature)
2. David also writes “This construct of decomposition of a whole into all of its parts is missing from both submissions” (Underlined caption is added by me). The problem here is one of abstraction. When is a decomposition of the whole into all of its parts complete? From whose perspective is it considered to be complete? Each question is addressed further below.
1. It can be argued that a decomposition is complete if it corresponds to the finalised bill of material for a product (realised or about to be realised). Before such a point in time there is no objective evidence that completeness has been attained. Any systems engineer can claim that an element is “decomposed into all parts” at any particular point in the engineering process, but there is no objective evidence for verifying such a claim.
2. The completeness of a specification is also dependent of who is reading it. A systems architect may hand over the complete architecture of a system to a productions engineer, who is bound to find it too abstract and very incomplete. I.e., I can only talk about completeness of an artefact if I can also specify the perspective from which I consider it to be complete. Conversely, wouldn’t it be more appropriate to assume that any approved artefact emanating from the SE process is complete given the purpose the artefact was created for? I.e., completeness is coupled to artefact approval.

 

Questions 1 and 2 may have arisen from a too strict interpretation of what is stated under issue 1.00, but given the information provided I would suggest INCOSE not to reject the SysML proposals reviewed.

 

Kind regards

 

 

Erik

 

Erik Herzog, Ph.D.

Syntell AB
PO Box 10022
S-100 55 Stockholm, Sweden
Tel. +46-(0)8-660 02 80
Mobile. +46-(0)70-541 82 57
Fax. +46-(0)8-660 09 65
her...@syntell.se
www.syntell.se
______________________________
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.

 

[David Oliver]

Clarification for the questions raised.

 

Question 1.

 

There is nothing in the concept of a "built from" construct that prohibits the definition of a component or block as a top level entity that has not yet been decomposed. At that point in the development it is a "black box". As an engineer does the work to generate a white box solution using usual systems enginering methods he develops refined behavior, refined MOE's, and refined structure. Typically behavior is allocated onto structure in a number of ways and this generates a set of alternative white box solutions. Performance analysis is performed to check these against requirements using the physical constants (parametric constraints) for the blocks of the alternative structurres. Only some alternative solutions meet requirements. then similar calculations are made using the MOE's to select a near optimal white box solution from the alternatives that remain.

 

The underlying concept in all of these engineering steps is that the engineer is naming all the pieces that the whole will be built from in the course of the behavior allocation, in the assignment of of parametric constraints and in the analysis. It is impossible to calculate the mass of the total thing if you do not know the masses of all the parts. The underlying construct needed in the language to represent this is "built from". The most frequent synonyms would be: to build, to assemble, to construct. The words representing the opposite activities would be: to take apart, to disassemble. Actual physical operations used would be like: nailing, bolting, screwing, welding, brazing, gluing, etc. All of these operations follow the laws of physics and engineering involving conservation of mass, energy, momentum, etc. All of phusical science deals with transformation under conservation laws.

 

There are other words used in the software discipline that do not apply to real physical things. These are words like: delete and create. They are found in some of the early graphic models like data flow diagams shere a thing can be split and sent to mutiple functions.

 

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.

 

There is a meaning of "built from" as a relationship of the whole and its parts. It is possible to disassemble the whole and the parts are left. If you take away all the parts, (put the building blocks of the tower back into the toy box) there is no tower left.

 

In the systems engineering world here is an entire life cycle phase that is missing in the software world. It is called Disposal. When this is done in a controlled fashon it is disassembly and yields the parts of the whole. If you leave your car in the wrong part of some cities it may be taken to a chop shop and reduced to its valuable parts that are sold into the illegal parts businesses for much more than the value of the car. Dispoal is extremely important right noiw in the earthquae raved parts of pakistan, the tsunami raved parts of Indonesia, and the hurricane raveged parts of the US. In this case both the whole and the parts are smashed, as can be represented by the relevant activity diagram to yield debrie as the output with consservation of mass.

 

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.

 

It is also true that the assertion of completeness is dependent upon who is assesrting it. Again this in no way reduces the need for the language to have expreswsion that allows the engineer to state in the language that this is complete for this purpose. it is well known that such assertions may be incorrect.

 

The VASA was built with a second gun deck at the insistence of the king placing the center of mass above the center of bouancy. adding enough ballast to correct this would submerge the lower gun ports. It sank.

 

The Takoma Narrows bridge was stated to have a complete design. However the engineers did not take into account the resonance of the structure with the formation and collapse of eddies in a strong wind. The bridge collapsed into the gorge.

 

 A hotel in Chicago was designed with high walkways in the atrium. The design was deemed complete with analysis to assure safety. However, the interfaces between the walkways and between the wlkways and the ceiling were inadequate in strength. The walkways fell under the weight of hotel guests killing many.

 

Whether the engineer does his job correctly or not, it is absolutely essential that his language allow him to assert that his design is complete in the context he is specifying. The balck diamond does not do tjhis even for the simple exercise of decomposition into parts. In most physical situations there are independent quality examinations to ensure that this is the case when the designed entity is built.

 

It is interesting that at this point of time in SysML development that this discussion  is continuing. The absence of the "built from" construct and others in UML was the motivation in INCOSE MDSD for initiating the the SysML program. The need for SysML could not be better demonstrated by the fact one of the basic needs that caused the project to be instituted is still  unmet and being questioned. This particular construct, "built from", wasa reased as a need by the systems community at the RFI for UML 2.0 and at every review of SysML since then. Its absence from the curerent submissions is testament to the very need for SysML.

 

Dave Oliver

[Branislav Selic]

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

[David Oliver]

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

[James N Martin]

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" <DOLI...@tampabay.rr.com> Sent by: SysML-Ev...@googlegroups.com 12/28/2005 06:46 AM Please respond to SysML-Ev...@googlegroups.com

To <SysML-Ev...@googlegroups.com> cc

[Michael Latta]

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-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of James N Martin
Sent: Wednesday, December 28, 2005 7:04 AM
To: SysML-Ev...@googlegroups.com

[David Oliver]

Gentlemen,

 

It is true that not all things that we model are matter or energy. We also model information. The point here is that systems engineers DO model energy and matter. These do not disappear. SysML has no appropriate decomposition construct for matter and energy. It does handle information quite well because UML was developed for this purpose and it has the black diamond. SysML was conceived to add the constructs that can also handle matter and energy. It is still lacking the basic construct for decompositions of the "built from" kind. The "built from" construct still needs to be added. This was first identified at the RFI for UML 2 many years ago.

 

I am not thinking only of purely physical systems. Most modern systems contain both physical parts energy, and information parts. We need the basic constructs for them all. That includes "built from" for matter and energy.

 

Please join in the movement to get this needed construct.

[James N Martin]

Michael,

Thanks for the follow-up.  I suspected that SysML, as you say, can model non-physical systems.  I just wanted to make sure I understood its intended scope.

In my view of SE there is *always* a logical component that corresponds to each physical component.  There is often more than one physical component that maps to each logical component.  Now it is quite true that in many cases the logical "corollary" to each physical component is not explicitly modeled. But, in many of those cases I have found that the SE in failing to fully understand the logical underpinnings of the physical things has overlooked some useful, more generic characteristics that can be built into the system. This logical level analysis can help discover potential common "blocks" that can then be customized for more specific applications (perhaps the current application in mind plus other unimaginable, for the moment, applications).  

As for the comm link, there is indeed the logical link.  But there is also the physical link which must be modeled, typically using a mechanism called a link budget. The physical comm link is a component of the system, but not one of the system "products" that gets delivered to the field. The system component in this case is created as the need arises when the relevant conditions and constraints are met. I did the first ten years of my career working mobile telecom so this sort of thing is pretty natural for me to think of the system (ie, model the system) in this manner. I find it disturbing to find that most SEs cannot do any "logical" modeling even if their life depended on it.  More and more, I believe, the complex systems of today depend on this logical modeling to fully understand their behavior and operational capabilities (even for supposedly hardware-only systems).

James

"Michael Latta" <lat...@mac.com> Sent by: SysML-Ev...@googlegroups.com 12/28/2005 11:59 AM

[James N Martin]

David,

Do not be deceived -- energy and matter CAN be made to disappear.  It's all described in my physics books. (Just joshing you.)

James

"David Oliver" <DOLI...@tampabay.rr.com> Sent by: SysML-Ev...@googlegroups.com

12/28/2005 12:38 PM

[Loyd...@aol.com]

We are 3SL agreed.

 

 

In a message dated 12/28/2005 11:39:18 AM Central Standard Time, DOLI...@tampabay.rr.com writes:

Gentlemen,

 

It is true that not all things that we model are matter or energy. We also model information. The point here is that systems engineers DO model energy and matter. These do not disappear. SysML has no appropriate decomposition construct for matter and energy. It does handle information quite well because UML was developed for this purpose and it has the black diamond. SysML was conceived to add the constructs that can also handle matter and energy. It is still lacking the basic construct for decompositions of the "built from" kind. The "built from" construct still needs to be added. This was first identified at the RFI for UML 2 many years ago.

 

I am not thinking only of purely physical systems. Most modern systems contain both physical parts energy, and information parts. We need the basic constructs for them all. That includes "built from" for matter and energy.

 

Please join in the movement to get this needed construct.

 

David

 

Loyd Baker
3SL Inc
Huntsville, Al
256-722-5020
Loyd....@threesl.com

[Loyd...@aol.com]

Sorry for the poor spelling. Let me try again.

 

We at 3SL agree.

 

thanks

 

Loyd Baker

3SL Inc.

----- Original Message -----

[Branislav Selic]

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" <lat...@mac.com> Sent by: SysML-Ev...@googlegroups.com

12/28/2005 11:59 AM Please respond to SysML-Evaluators

To <SysML-Ev...@googlegroups.com> cc Subject [sysml-submission-team] [SysML-Evaluators] Re: Clarification request DWO issue 1.00

[Michael Latta]

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-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Branislav Selic
Sent: Wednesday, December 28, 2005 11:58 AM
To: SysML-Ev...@googlegroups.com
Cc: SysML-Ev...@googlegroups.com
Subject: [SysML-Evaluators] Re: [sysml-submission-team] [SysML-Evaluators] Re: Clarification request DWO issue 1.00

[Branislav Selic]

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: bse...@ca.ibm.com

"Michael Latta" <lat...@mac.com> Sent by: SysML-Ev...@googlegroups.com

12/28/2005 04:01 PM Please respond to SysML-Evaluators

To <SysML-Ev...@googlegroups.com> cc Subject

[Michael Latta]

I do not believe this really does it.  White diamond notation has the following properties:

 

1) Shared ownership.

2) Destruction of the owner has no defined semantics on the children.

 

What I think David is looking for is:

 

1) Exclusive ownership.

2) Destruction of owner destroys children.

 

The issue of disassembly is different and currently missing from the defined semantics.  However the lower multiplicity of the child end would need to be 0 to imply disassembly was possible.

 

I think you are suggesting that if the conceptual thing is a logical entity then the difference between made from and contains is not meaningful.  I would like David to comment on that.  Certainly it is possible to use multiplicity to indicate that parts are required to be present for the whole to be present.

 

Since neither SysML submission has white diamond it does not cover this discussion in any case.

 

Michael

 

 

---

From: SysML-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Branislav Selic

Sent: Wednesday, December 28, 2005 2:16 PM

[Branislav Selic]

Aaah, we now down to the nitty gritty:

> What I think David is looking for is:
>  
> 1) Exclusive ownership.

I am not convince that this is what he wants -- athough he can get that easily by simply using a multiplicity of 0..1 at the owner end. However, a tire is just as much a part of the car as is it is a part of the wheel. I suspect that people will want more than exclusive ownership.

> 2) Destruction of owner destroys children.

??? this makes no sense. David just finished explaining that physical parts do not go away when the whole is destroyed. What goes away is the role that they were playing in the whole.

> I think you are suggesting that if the conceptual thing is a logical
> entity then the difference between made from and contains is not
> meaningful.  I would like David to comment on that.  Certainly it is
> possible to use multiplicity to indicate that parts are required to
> be present for the whole to be present.

What I am saying is that all "wholes" in the sense that dave is talking about are logical.

> Since neither SysML submission has white diamond it does not cover
> this discussion in any case.

I am surprised to hear this. In either case, it is easily handled by simply allowing that capabilty.

Thanks...Bran

[Michael Latta]

My second point is that there is a difference between destruction and disassembly.  If I put a car in a masher all the parts of the car are mashed, not just the conceptual "car".  Removal of parts from the whole leaves them intact, destruction of the whole destroys the parts as well.  I really think the key part of what David is after is that when you remove all parts of a car there is nothing left.  The set of all "built from" constitute the whole with no remainder.  In the software world this is different as you do not dissect an object in quite the same way, and do not discuss removing the slots for holding properties from the object itself.  The object has intrinsic content that can not be removed.

 

We do seem to be getting too many things muddled together.  I believe this has always been an issue with UML since there are so many semantics being convolved onto one association end annotation.  It might be better to have SysML separate these semantics as was suggested in one UML 2.0 proposal.  Have the ownership, destruction, and whole/part completeness semantics each be a separate annotation.  This might be a better direction to take in resolving this issue.

 

Michael

 

 

---

From: SysML-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Branislav Selic

Sent: Wednesday, December 28, 2005 3:27 PM

To: SysML-Ev...@googlegroups.com
Cc: SysML-Ev...@googlegroups.com
Subject: [SysML-Evaluators] Re: [sysml-submission-team] [SysML-Evaluators] Re: Clarification request DWO issue 1.00

[Branislav Selic]

While I agree that things are getting muddled here, it seems to me that--at least in this case--this is not a problem with UML but in the way it is being used. The difference between destruction and disassembly belongs to the realm of behavior and not to the realm of structure. UML separates these things nicely and so should we.

Bran

"Michael Latta" <lat...@mac.com> Sent by: SysML-Ev...@googlegroups.com

12/28/2005 06:42 PM Please respond to SysML-Evaluators

To <SysML-Ev...@googlegroups.com> cc

[Erik Herzog]

David,

 

Many thanks for your long reply. I have been away skiing during the holiday period so I have not been able to respond any sooner, but the clarifications provided seems in large to avoid the key issues raised in the original mail. Yet, the debate provoked has been very interesting to follow. I believe there are two important issues that need to be addressed.  

 

1. Is the capability called for in issue 1.00 appropriate?
2. Are the solutions provided by both SysML submissions really inappropriate?

 

My apologies for providing a very long e-mail, but the issue is far from being trivial.

 

1. As issue 1.00 is documented it calls for a capability to capture “Decomposition into all parts”. David, you write that

 

“Whether the engineer does his job correctly or not, it is absolutely essential that his language allow him to assert that his design is complete in the context he is specifying. The black diamond does not do this even for the simple exercise of decomposition into parts. In most physical situations there are independent quality examinations to ensure that this is the case when the designed entity is built.”

 

I would argue that the position you take is inappropriate regardless whether the UML black diamond (composition) or a built from relationship is used. Completeness is a quality attribute of a model (normally captured through some kind of approval property) rather than something that can be asserted on a set of parent child relationships. Keep in mind that a unique relationship object connects each child in a structure with its immediate parent. The technique in UML where one diamond connects the parent to its children is just a shorthand notation, in reality there is one relationship per child object. Note that this is not just a UML specific solution. Composition is handled in this way in all competent modelling environments (and of course within STEP too).

With this in mind I am sure you agree that it is inappropriate to map completeness to individual parent child relationships.

 

So if the SysML submissions are inappropriate today, then the proposed solution is definitely not any better. “Decomposition into all parts” can not be determined in the decomposition relationship itself. In order to preserve INCOSE’s credibility in the interaction with external organisations we need to make sure that proposals made are realistic.

 

2.       It can however be argued that the UML composition (black diamond) semantics is inappropriate for capturing real physical systems. The black diamond implies that the lifespan of the parts depends on the lifespan of the parent. I.e., the instantiation of an aggregate (say a car) implies that the life of the parts of the car is controlled by the car itself. This is clearly against the behaviour of physical parts, but is it a problem for SysML?

 

Representation of physical structure has for a long time been in use in mechanical engineering, i.e., product structures. These are well understood and properly documented in standards like STEP application protocols. Model based systems engineering also includes the notion of physical structure. The question is whether they refer to the same physical structures or whether they are two separate ones. David appears to take the position that they are indeed the same physical structures by stating in issue 1.00 that

 

“Manufacturing will be very upset if you give them a list with only some of the parts to make the whole. The entire factory process and factory design is predicated on knowing all of the parts. Analysis is mandatory for performance calculations.”

           

This concern is true for a product structure where the weight of the whole can be calculated from the sum of the weight of the parts.

 

However, I would argue that we are faced with a homonym and that the physical structures identified in model based systems engineering are of another nature than traditional product structures (David, if you remember we had a similar discussion a year ago when you were modelling for AP-233). In an earlier response in this conversation James Martin uses the terms logical and physical components (where I assume the physical components corresponds to the elements in the product structure). Using this separation the logical architecture is a requirement representation for the physical structure that is to be realised, and not the blueprints for the structure. The creation of the blueprints, i.e., the product structure for manufacturing is handled by domain engineers using proven domain engineering tool. It is true that systems engineering is included in this phase of the engineering process as well, but the primary responsibility lies with the domain engineers (and the design will reside in their tools). The interface to manufacturing is through domain engineering and not through systems engineering. Note that this separation concurs with requirements best practise. Requirements shall state what shall be accomplished, not how.

 

Many of the properties valid for the product structure are not valid for the logical architecture. It is entirely valid for the weight of a logical composite to be less of more than the weights of its individual parts. The discrepancy could be due to a design decision by the systems engineer to keep a positive of negative weight reserve to accommodate for unforeseen changes. The logical architecture is also typically built top down, i.e., a “logical car” is still a “logical car” even if I take away all of its components. Properties such as weight still remain as they are only required values. Moreover, the properties of the composition relationship are of less concern as the logical elements do not necessarily equal the physical elements that will be realised.

 

So the question is whether of these architecture are in scope for SysML?

 

It has always been my assumption that the block models in SysML are intended to capture the logical components and not the physical ones. The rationale for this assumption are:

 

1. SysML is primarily a tool for systems engineers it is not the engineering-do-it-all tool. (Imagine SysML as a replacement for your organisation’s PDM tools -  it may be fancy, but can it manage your configurations? No!).
2. SysML does not include support for representation of part numbers (essential for interface to manufacturing, but irrelevant for logical elements). Not to mention the lack for support for representing geometry etc.

 

With the reasoning provided above I would urge INCOSE not reject the SysML submissions on this issue. I would also encourage a view where SysML is not assessed against our ultimate desires for a systems modelling language but against the real world constraints posed by the limited resources available and the constraints imposed by the UML itself. We need to look to other frameworks for realising the support environment which incorporates all engineering disciplines with a proper CM infrastructure. For those who don’t know me and my preferences – STEP!

 

Kind regards

 

Erik

---

[Michael Latta]

It seems to me you are making the following arguments/points:

 

1) Completeness should be a property of every aspect of a model, not just composition.

2) Composition implies equal lifetimes.

3) SysML should not attempt to provide for "domain" engineering, but focus on requirements.

 

I would make the following:

 

1) I agree that completeness should be a measure on all aspects of the model, and could actually be modeled as a step in a lifecycle of model elements.  The differences between requirements and design are important, as well as the completeness.  Some aspects of a model may be requirements complete, but design incomplete, while others are requirements incomplete, and others are design complete.

2) The semantics defined for UML composition relate to destruction of the owning object implying destruction of the child.  This is not about lifelines.  It is quite possible to remove an object from a UML composition or add to one as part of the dynamic behavior or lifecycle of a component.  The issue is really with composition vs. built from semantics.

3) While requirements management and tracking is a large part of a system engineering process, it is certainly not all of it.  Some systems engineers do far more engineering than others.  I would expect in a majority of cases the systems engineering effort is responsible for defining to some level of detail the to-build system specifications relating to components, their interfaces, and their behavior.  I would also expect a degree of verification effort to exist with most system engineering efforts.  Therefore I do not consider it inappropriate for systems engineers to want to track part numbers, represent individual verification cases (either as exemplary of failure, success, or to make an engineering point).  This is also important to representing alternative design options that satisfy or fail to satisfy requirements.  I have seen systems engineering models detailed enough to predict failure of a satellite communications protocol given factors such as orbital mechanics, communications protocol behavior, and relative motion of the network of satellites.  While that may be an extreme case, the larger projects do a large amount of engineering within the systems engineering effort and existing system engineering tools.

 

Michael

---

From: SysML-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Erik Herzog
Sent: Tuesday, January 03, 2006 3:13 AM
To: SysML-Ev...@googlegroups.com
Subject: [SysML-Evaluators] Re: Clarification request DWO issue 1.00

[Erik Herzog]

Michael,

 

Please find my comments in black text inserted below.

 

Kind regards

 

Erik

 

---

From: SysML-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Michael Latta
Sent: den 3 januari 2006 22:01
To: SysML-Ev...@googlegroups.com
Subject: [SysML-Evaluators] Re: Clarification request DWO issue 1.00

 

It seems to me you are making the following arguments/points:

 

1) Completeness should be a property of every aspect of a model, not just composition.

2) Composition implies equal lifetimes.

3) SysML should not attempt to provide for "domain" engineering, but focus on requirements.

 

I would make the following:

 

1) I agree that completeness should be a measure on all aspects of the model, and could actually be modeled as a step in a lifecycle of model elements.  The differences between requirements and design are important, as well as the completeness.  Some aspects of a model may be requirements complete, but design incomplete, while others are requirements incomplete, and others are design complete.

<EH>

My apologies for being unclear. What I had in mind was a more fine grained solution. In STEP I would associate approvals with a product_view_Definition object which would correspond to, e.g., a class. For composite structure I could define the approval as having a transitive scope.

</EH>

2) The semantics defined for UML composition relate to destruction of the owning object implying destruction of the child.  This is not about lifelines.  It is quite possible to remove an object from a UML composition or add to one as part of the dynamic behavior or lifecycle of a component.  The issue is really with composition vs. built from semantics.

<EH>

We are obviously in agreement with regard to UML semantics. What I said was that the composite element controls the life of its constituent  parts. I was trying to illustrate the UML composition semantics is not equal to the semantics of a built from relationship.

</EH>

 

3) While requirements management and tracking is a large part of a system engineering process, it is certainly not all of it.  Some systems engineers do far more engineering than others.  I would expect in a majority of cases the systems engineering effort is responsible for defining to some level of detail the to-build system specifications relating to components, their interfaces, and their behavior.  I would also expect a degree of verification effort to exist with most system engineering efforts.  Therefore I do not consider it inappropriate for systems engineers to want to track part numbers, represent individual verification cases (either as exemplary of failure, success, or to make an engineering point).  This is also important to representing alternative design options that satisfy or fail to satisfy requirements.  I have seen systems engineering models detailed enough to predict failure of a satellite communications protocol given factors such as orbital mechanics, communications protocol behavior, and relative motion of the network of satellites.  While that may be an extreme case, the larger projects do a large amount of engineering within the systems engineering effort and existing system engineering tools.

 

 

<EH>

Many complex systems are built from other complex systems (subsystems) which in turn are built from other complex systems. In a top down development approach I would create a system model of sufficient detail to capture the overall system architecture including requirements, functional architecture (behaviour) and system components. I would then baseline my model and hand it off to my subsystem suppliers (in-house or external) for allowing them to create their (sub)system model until the point where domain (realisation) engineering can start.  In this perspective all system engineering models are requirements that guide the development of other engineering efforts. The difference is that the SE models are built top down (the properties of the parent are allocated down to its children) and product structures are built bottom up (the properties of the children are aggregated in the parent).

 

I will of course use the system models in my verification and validation efforts as they define my desired system. Verification will be performed against the information captured in the model. However, I do not expect the system  model to include part numbers as part identification would mean that the systems engineer had requested ‘hows’ rather than ‘whats’. As a part of my verification activities I also need to keep track on what I verified against. I.e., the exact realised configuration of the verified part. This has previously been a weakness in SysML and from what I read in the requirements chapter of the respective submission it has not been fixed.

 

A final note. Systems engineers will of course come across situations where it is more appropriate to work in the tools of domain engineers and they should of course do so where it is appropriate. But we should not try to stretch SysML such that it covers some minimal aspects of all engineering disciplines. SysML is not the engineering integration vehicle and will never be, STEP is.

</EH>

[David Oliver]

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

[David Oliver]

Gentlemen,

 

There are many engineering occasions in which the subject of engineering is not considered a logical entity. It is a physical entity that follows the laws of science, such as the conservation laws. Performance analysis and trade studies are applied. these are only valid if the analysis has been verified to be correct for the problem under consideration. On these occasions no entity disappears. It can be transformed in accordance with physical laws. Among the representations needed for this is a "build from" relationship that enables one to list the parts that are to be put together in a hierarchy. (There are other important relationships that are needed to describe how the parts go together)

 

In paractical engineering there is no one si ngle list and it ev olves through the life cycle. There is a hierarchy that emerges from the design phase that manufacture can use to establish (with other information) how they can make the thing. the manufacturing hieraqrchy is more detqailed because it must include raw stock, etc. Theree is a different hierarchy for maintenance because some things are put together by processes like welding and maintenance will not take them apart. Raather maintenance works with line replaceable units and the ability to diagnose problems to that level of detail; which LRU needs to be replaced. Disposal has a different hierarchy based on in part how the entity will be separated for recycling. The needed "built from" hieraqrchy depends on life cycle phase. But in none of these phases can anything be made to disappear. many towns in Missippi and Lousiana wish hat were not so.

 

david

----- Original Message -----

From: Branislav Selic

To: SysML-Ev...@googlegroups.com

Cc: SysML-Ev...@googlegroups.com

Sent: Wednesday, December 28, 2005 6:26 PM

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

[Branislav Selic]

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: bse...@ca.ibm.com

"David Oliver" <DOLI...@tampabay.rr.com> Sent by: SysML-Ev...@googlegroups.com

01/04/2006 03:21 PM

[David Oliver]

Bran,

 

It is important to realize that even in the systems engineering development phases that it is often necessary to track the particular parts that go into a system, the supplieres lot of material that was used in manufacture and the tools used to produce the entity. When the first development physical products undergo test some of them always fail. We would prefer not, but they do. One cannot decide the cause of failure in many situations without knowing the identity of the whole and the identity of its parts and from those identities the manufacture and procurement history. This is all physical world stuff.

 

The automobile is not jalways just a conceptual notion for a collection of interacting parts. In many (not all cases) the automobile and all or many of its parts have an identity that is maintained and can be tracked through the procurement, manufacturing, use and maintenance processses.

 

This also continues in production phases, especially for safety critical items. If one of these fails in service, it may be required thqt the manufacturer can trace the particular paarts in the failed thing (perhaps aircraft engine) back to the ingots and forgings supplied to make the parts.

 

Software doesnt have to deal with the titanium ingot from a supplier with small hard alpha phases that went undetected and caused the aircraft to blow up and kill 300 people. This need for both a "build from" construct, and the notion of identity of the whole and its parts have generally not been needed in the software world. This precisely why SysML is needed and we are having these discussions. It would be great if the open diamond can satisfy the system need. I will continue listening to the UML experts.

 

Dave

[David Oliver]

Bran,

 

It is important to realize that even in the systems engineering development phases that it is often necessary to track the particular parts that go into a system, the supplieres lot of material that was used in manufacture and the tools used to produce the entity. When the first development physical products undergo test some of them always fail. We would prefer not, but they do. One cannot decide the cause of failure in many situations without knowing the identity of the whole and the identity of its parts and from those identities the manufacture and procurement history. This is all physical world stuff.

 

The automobile is not jalways just a conceptual notion for a collection of interacting parts. In many (not all cases) the automobile and all or many of its parts have an identity that is maintained and can be tracked through the procurement, manufacturing, use and maintenance processses.

 

This also continues in production phases, especially for safety critical items. If one of these fails in service, it may be required thqt the manufacturer can trace the particular paarts in the failed thing (perhaps aircraft engine) back to the ingots and forgings supplied to make the parts.

 

Software doesnt have to deal with the titanium ingot from a supplier with small hard alpha phases that went undetected and caused the aircraft to blow up and kill 300 people. This need for both a "build from" construct, and the notion of identity of the whole and its parts have generally not been needed in the software world. This precisely why SysML is needed and we are having these discussions. It would be great if the open diamond can satisfy the system need. I will continue listening to the UML experts.

 

Dave

[Erik Herzog]

David,

 

I really hate picking on what you write. But, are you seriously suggesting the inclusion of AP-214 and PLCS (STEP AP 239) into SysML?

 

Kind regards

 

Erik

 

---

[Chonoles, Michael J]

Bran

As far as I remember there is a minor difference between regular association and white diamond association (aggregation), that is, when there is a reflexive (self) relationship (relationships between elements of the same class/type)

 

There's an inherent asymmetry with aggregation that prevents loops in the hierarchy that  is not prevented with regular association. For example, if one was going to the relationship of blocks to other blocks in a class-like diagram you would use aggregation and not association. Any block can contain lots of other blocks, but you'd like to prevent a block from containing any other block that  contains itself (no loops).

 

Composition (black diamond) also has the same restriction, but adds the additional restriction that a block can only be contained in no more than one other block. This is usually the case for physical parts, but a logical subsystem could be part of  many logical systems (but never part of a system that it also contains).

 

I would argue that association, aggregation, and composition are all sufficiently distinct in reflexive associations that they should all be retained. However, it appears that most of the time Dave's whole-part relationships should be white-diamond if they need to enforce the no-loop constraint.

Michael Jesse Chonoles
Principal Member of Engineering Staff
Enterprise Architecture
Lockheed Martin Maritime Systems & Sensors (MS2)
199 Borton Landing Rd, MS 780-2A, Moorestown, NJ, 08057
Phone 856 359-1383
Lockheed Martin IS&S King of Prussia, PA
Phone 610 644-8404
michael.j...@lmco.com
Co-author UML 2 For Dummies
(215) 790-2976 Fax
(609) 760-2180 Mobile
OMG-Certified UML Advanced Professional

 

 

---

From: SysML-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Branislav Selic

Sent: Wednesday, January 04, 2006 3:45 PM

To: SysML-Ev...@googlegroups.com
Cc: SysML-Ev...@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 disappearance 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: bse...@ca.ibm.com

"David Oliver" <DOLI...@tampabay.rr.com> Sent by: SysML-Ev...@googlegroups.com 01/04/2006 03:21 PM Please respond to SysML-Evaluators

To <SysML-Ev...@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 and this provides the solution we need.

 
david 
 ----- Original Message -----
From: Branislav Selic
To: SysML-Ev...@googlegroups.com
Cc: SysML-Ev...@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 diamond" notation.

> performance can be done. The initial level of fidelity 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 engineering.

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