Issue 9794: regarding the <<requirementRelated>> stereotype in the Requirements package section 1.21.3 IDLEntity () Source: The MathWorks (Mr. Alan Moore, alan.moore@mathworks.co.uk) Nature: Clarification Severity: Summary: regarding the <<requirementRelated>> stereotype in the Requirements package of the SysML profile. I have two questions: Why is the “verifies” tag on requirementRelated instead of <<testcase>>? Why do you allow <<requirementRelated>> to be applied to <<testcase>> items? It makes more sense to me to put the “verifies” tag on <<testcase>> and have a constraint on <<requirementRelated>> that states it cannot be applied to items stereotyped as <<testcase>>. As I understand it <<requirementRelated>> is basically a placeholder for the derived tags that can’t go anywhere else (e.g. “satisfies”, etc). Since <<testcase>> is already a stereotype there’s no reason why it can’t hold the “verifies” tag. Resolution: Revised Text: 16.3.2.4 RequirementRelated (from Requirements) Description This stereotype is used to add properties to those elements that are related to requirements via the various dependencies described in Figure 16.1. The property values are shown using call-out notation (i.e., notes) as shown in the diagram element table. Attributes \verifies: Requirement[*]Derived from all requirements that are the supplier of a <<verify>> relationship for which this element is a client. o \satisfies: Requirement[*]Derived from all requirements that are the supplier of a <<satisfy>> relationship for which this element is a client. o \refines: Requirement[*]Derived from all requirements that are the supplier of a <<refine>> relationship for which this element is a client. o \tracedFrom: Requirement[*]Derived from all requirements that are the supplier of a <<trace>> relationship for which this element is a client. 16.3.2.5 TestCase (from Requirements) Description A method for verifying a requirement is satisfied. Attributes \verifies: Requirement[*]Derived from all requirements that are the supplier of a <<verify>> relationship for which this element is a client. Constraints [1]The type of return parameter Actions taken: May 26, 2006: received issue July 30, 2007: closed issue Discussion: The submitter is right in the sense that only <<testcase>> can be used to verify requirement. The derived properties Verifies in the RequirementRelated Stereotype will never be filled unless the stereotype is applied to a testcase. Therefore, the Verifies property can be removed from the RequirementRelated stereotype. Revise the text in section 16.3.2.4 to reflect that Verifies does not belong anymore to the stereotype RequirementRelated. Update 16.3.2.5 to reflect that a new derived property called Verifies is added to the stereotype. I disagree with the second part of the issue "have a constraint on <<RequirementRelated>>" because a test case can still be traced, satisfy or refine a requirement. Therefore no constrain should be added. Update the Figures 16.1 and 16.2 accordingly. End of Annotations:===== Reply-To: From: "Conrad Bock" To: "'Jack Low'" , Subject: RE: Draft Ballot for 2006-08-14 Date: Mon, 7 Aug 2006 20:02:40 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca6NPAWNIyMgraUTIy+foQ+TfiPKwASLvag Hi Jack, One comment on the the ballot: - 9794 (Derived properties for requirements) The Revised Text section has discussion that should be in the Resolution seciton. The Revised Text section should give the exact change in the text. Conrad ubject: FW: SysML Profile (ad/2006-03-01) Date: Fri, 26 May 2006 17:00:39 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SysML Profile (ad/2006-03-01) Thread-Index: AcaA3PMF3ew+RM7YQg2Seci3rzyqNwAAA8hQAAAWMDA= From: "Moore, Alan" To: "Juergen Boldt" Hi Juergen, My colleague.s e-mail bounced . does he have to subscribe in order to send to issues@omg.org? Alan. -------------------------------------------------------------------------------- From: Astle, Phil Sent: 26 May 2006 16:58 To: Moore, Alan Subject: FW: SysML Profile (ad/2006-03-01) I tried sending it and it bounces with an .undeliverable. message from the system administrator. I.m guessing the .from. list is filtered. -------------------------------------------------------------------------------- From: Astle, Phil Sent: 26 May 2006 16:56 To: 'issues@omg.org' Subject: SysML Profile (ad/2006-03-01) Hi, I.m emailing regarding the <> stereotype in the Requirements package of the SysML profile. I have two questions: Why is the .verifies. tag on requirementRelated instead of <>? Why do you allow <> to be applied to <> items? It makes more sense to me to put the .verifies. tag on <> and have a constraint on <> that states it cannot be applied to items stereotyped as <>. As I understand it <> is basically a placeholder for the derived tags that can.t go anywhere else (e.g. .satisfies., etc). Since <> is already a stereotype there.s no reason why it can.t hold the .verifies. tag. I hope this makes sense. Regards, Phillip Astle Product Marketing Engineer ARTiSAN Software Tools ' +44(1242) 229308 7 +44(1242) 229301 * phil.astle@artisansw.com X-Server-Uuid: 9F05637B-5F0B-4B0D-B258-A74412BA6C84 X-Server-Uuid: 1582A0E2-1096-4E85-9F0B-52DE92C41388 Subject: Issues 9785 and 9794 on current ballot Date: Thu, 17 Aug 2006 10:45:24 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues 9785 and 9794 on current ballot Thread-Index: Aca/y2I+ksHEpbJaSV6m4lUgC7TAVAAAgQCAAJBOuXA= From: "Burkhart Roger M" To: sysml-ftf@omg.org X-OriginalArrivalTime: 17 Aug 2006 15:45:24.0782 (UTC) FILETIME=[27B314E0:01C6C214] X-WSS-ID: 68FA509D3IK47042-01-01 X-TMWD-Spam-Summary: TS=20060817154533; SEV=2.0.1; DFV=A2006081710; IFV=2.0.4,4.0-8; RPD=4.00.0004; ENG=IBF; RPDID=303030312E30413031303230342E34344534384533372E303035322D462D7A755566344A346E6A486F7551512B55754C6A714F513D3D; CAT=NONE; CON=NONE X-MMS-Spam-Filter-ID: A2006081710_4.00.0004_4.0-8 X-WSS-ID: 68FA50981N480203-03-01 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k7HFj3kp010647 On Issue 9785, the initial Lockheed vote of "no" indicates, "I prefer not to change the definition of view." The proposed change is to insert "or subsystem" in the new definition, "A view is a representation of a whole system or subsystem from the perspective of a single viewpoint." Since I haven't seen any discussion on the mailing list about the issue, I'll just note that a "whole system" could be overly restrictive (not to mention undefined), and so I'll vote yes in favor of the new text, which clarifies the flexibility to use views at any level of a system in a system hierarchy. On Issue 9794, Conrad wrote: > I didn't see any response to my comment on 9794, see below. It seems > like we shouldn't vote on it if the text changes are given in the > resolution. Some of it is a submitter opinion, rather than a > resolution. > One comment on the the ballot: > > - 9794 (Derived properties for requirements) > > The Revised Text section has discussion that should be in the > Resolution seciton. The Revised Text section should give the > exact change in the text. I don't know if this was already fixed, but the Revised Text does now have only revised text, but the replacement text is incomplete, ending with a fragment of the former text under Constraints, with "[1] The type of return parameter". The full text in the current spec is "[1] The type of return parameter of the stereotyped model element must be VerdictKind. (note this is consistent with the UML Testing Profile)." For clarity of instructions to the editors, I suggest that Revised Text sections either completely replace a section, or indicate when they're only referring to surrounding text that's to be left unmodified. I will vote yes on the issue assuming that the intent is clear, but I agree with Conrad that final text changes should always be clear in the Revised Text section. --Roger Date: Thu, 17 Aug 2006 15:34:32 -0400 From: "Friedenthal, Sanford" Subject: RE: Issues 9785 and 9794 on current ballot To: Burkhart Roger M , sysml-ftf@omg.org Thread-Topic: Issues 9785 and 9794 on current ballot Thread-Index: Aca/y2I+ksHEpbJaSV6m4lUgC7TAVAAAgQCAAJBOuXAACR02EA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 17 Aug 2006 19:34:30.0732 (UTC) FILETIME=[28EC98C0:01C6C234] Roger, SysML FTF I had some concern about modifying the defintion of view to insert "or subsystem". I think a view of a "whole system" already can accomodate a view of a "whole subsystem". The view of the system is just defined from a subsystem stakeholder perspective. If we want to generalize the definition, I would think the term "whole system" should be replaced by "whole model", but I didn't want to start down that path at this time. The current definition is pretty much the IEEE 1471 definition. I recommend we stick with the current standard definition for now. I registered a "No" vote to this proposed resolution. Sandy -----Original Message----- From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Thursday, August 17, 2006 11:45 AM To: sysml-ftf@omg.org Subject: Issues 9785 and 9794 on current ballot On Issue 9785, the initial Lockheed vote of "no" indicates, "I prefer not to change the definition of view." The proposed change is to insert "or subsystem" in the new definition, "A view is a representation of a whole system or subsystem from the perspective of a single viewpoint." Since I haven't seen any discussion on the mailing list about the issue, I'll just note that a "whole system" could be overly restrictive (not to mention undefined), and so I'll vote yes in favor of the new text, which clarifies the flexibility to use views at any level of a system in a system hierarchy. On Issue 9794, Conrad wrote: > I didn't see any response to my comment on 9794, see below. It seems > like we shouldn't vote on it if the text changes are given in the > resolution. Some of it is a submitter opinion, rather than a > resolution. > One comment on the the ballot: > > - 9794 (Derived properties for requirements) > > The Revised Text section has discussion that should be in the > Resolution seciton. The Revised Text section should give the > exact change in the text. I don't know if this was already fixed, but the Revised Text does now have only revised text, but the replacement text is incomplete, ending with a fragment of the former text under Constraints, with "[1] The type of return parameter". The full text in the current spec is "[1] The type of return parameter of the stereotyped model element must be VerdictKind. (note this is consistent with the UML Testing Profile)." For clarity of instructions to the editors, I suggest that Revised Text sections either completely replace a section, or indicate when they're only referring to surrounding text that's to be left unmodified. I will vote yes on the issue assuming that the intent is clear, but I agree with Conrad that final text changes should always be clear in the Revised Text section. --Roger Subject: RE: Issues 9785 and 9794 on current ballot Date: Fri, 18 Aug 2006 08:02:50 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues 9785 and 9794 on current ballot thread-index: Aca/y2I+ksHEpbJaSV6m4lUgC7TAVAAAgQCAAJBOuXAACR02EAAWIOcA From: "Tim Weilkiens" To: "Friedenthal, Sanford" , "Burkhart Roger M" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k7I627NQ017752 I think one major problem is that we have no clear definition of a system and subsystem. That makes it difficult. Different people have different views on these technical terms. Tim > -----Original Message----- > From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] > Sent: Thursday, August 17, 2006 9:35 PM > To: Burkhart Roger M; sysml-ftf@omg.org > Subject: RE: Issues 9785 and 9794 on current ballot > > Roger, SysML FTF > > I had some concern about modifying the defintion of view to > insert "or subsystem". I think a view of a "whole system" > already can accomodate a view of a "whole subsystem". The > view of the system is just defined from a subsystem > stakeholder perspective. If we want to generalize the > definition, I would think the term "whole system" should be > replaced by "whole model", but I didn't want to start down > that path at this time. > The current definition is pretty much the IEEE 1471 > definition. I recommend we stick with the current standard > definition for now. I registered a "No" vote to this proposed > resolution. > > Sandy > > -----Original Message----- > From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] > Sent: Thursday, August 17, 2006 11:45 AM > To: sysml-ftf@omg.org > Subject: Issues 9785 and 9794 on current ballot > > On Issue 9785, the initial Lockheed vote of "no" indicates, > "I prefer not to change the definition of view." The > proposed change is to insert "or subsystem" in the new > definition, "A view is a representation of a whole system or > subsystem from the perspective of a single viewpoint." > > Since I haven't seen any discussion on the mailing list about > the issue, I'll just note that a "whole system" could be > overly restrictive (not to mention undefined), and so I'll > vote yes in favor of the new text, which clarifies the > flexibility to use views at any level of a system in a system > hierarchy. > > On Issue 9794, Conrad wrote: > > > I didn't see any response to my comment on 9794, see below. > It seems > > like we shouldn't vote on it if the text changes are given in the > > resolution. Some of it is a submitter opinion, rather than a > > resolution. > > > One comment on the the ballot: > > > > - 9794 (Derived properties for requirements) > > > > The Revised Text section has discussion that should be in the > > Resolution seciton. The Revised Text section should give the > > exact change in the text. > > I don't know if this was already fixed, but the Revised Text > does now have only revised text, but the replacement text is > incomplete, ending with a fragment of the former text under > Constraints, with "[1] The type of return parameter". The > full text in the current spec is "[1] The type of return > parameter of the stereotyped model element must be VerdictKind. > (note this is consistent with the UML Testing Profile)." > > For clarity of instructions to the editors, I suggest that > Revised Text sections either completely replace a section, or > indicate when they're only referring to surrounding text > that's to be left unmodified. I will vote yes on the issue > assuming that the intent is clear, but I agree with Conrad > that final text changes should always be clear in the Revised > Text section. > > --Roger > > > > To: "Tim Weilkiens" Cc: "Burkhart Roger M" , "Friedenthal, Sanford" , sysml-ftf@omg.org Subject: RE: Issues 9785 and 9794 on current ballot X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 From: Branislav Selic Date: Fri, 18 Aug 2006 03:21:44 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/18/2006 03:21:45, Serialize complete at 08/18/2006 03:21:45 These too can be taken from IEEE 1471. "system: a collection of components required to accomplish a specific function or set of functions" (A subsystem is clearly a system that is a component of a greater system.) Based on my UML experience with the term, I think it owuld be dangerous to go beyond this. Too many conflicting definitions lead to terminology wars and OMG-like philosophical discussions about ships and identity. 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 "Tim Weilkiens" 08/18/2006 02:02 AM To "Friedenthal, Sanford" , "Burkhart Roger M" , cc Subject RE: Issues 9785 and 9794 on current ballot I think one major problem is that we have no clear definition of a system and subsystem. That makes it difficult. Different people have different views on these technical terms. Tim > -----Original Message----- > From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] > Sent: Thursday, August 17, 2006 9:35 PM > To: Burkhart Roger M; sysml-ftf@omg.org > Subject: RE: Issues 9785 and 9794 on current ballot > > Roger, SysML FTF > > I had some concern about modifying the defintion of view to > insert "or subsystem". I think a view of a "whole system" > already can accomodate a view of a "whole subsystem". The > view of the system is just defined from a subsystem > stakeholder perspective. If we want to generalize the > definition, I would think the term "whole system" should be > replaced by "whole model", but I didn't want to start down > that path at this time. > The current definition is pretty much the IEEE 1471 > definition. I recommend we stick with the current standard > definition for now. I registered a "No" vote to this proposed > resolution. > > Sandy > > -----Original Message----- > From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] > Sent: Thursday, August 17, 2006 11:45 AM > To: sysml-ftf@omg.org > Subject: Issues 9785 and 9794 on current ballot > > On Issue 9785, the initial Lockheed vote of "no" indicates, > "I prefer not to change the definition of view." The > proposed change is to insert "or subsystem" in the new > definition, "A view is a representation of a whole system or > subsystem from the perspective of a single viewpoint." > > Since I haven't seen any discussion on the mailing list about > the issue, I'll just note that a "whole system" could be > overly restrictive (not to mention undefined), and so I'll > vote yes in favor of the new text, which clarifies the > flexibility to use views at any level of a system in a system > hierarchy. > > On Issue 9794, Conrad wrote: > > > I didn't see any response to my comment on 9794, see below. > It seems > > like we shouldn't vote on it if the text changes are given in the > > resolution. Some of it is a submitter opinion, rather than a > > resolution. > > > One comment on the the ballot: > > > > - 9794 (Derived properties for requirements) > > > > The Revised Text section has discussion that should be in the > > Resolution seciton. The Revised Text section should give the > > exact change in the text. > > I don't know if this was already fixed, but the Revised Text > does now have only revised text, but the replacement text is > incomplete, ending with a fragment of the former text under > Constraints, with "[1] The type of return parameter". The > full text in the current spec is "[1] The type of return > parameter of the stereotyped model element must be VerdictKind. > (note this is consistent with the UML Testing Profile)." > > For clarity of instructions to the editors, I suggest that > Revised Text sections either completely replace a section, or > indicate when they're only referring to surrounding text > that's to be left unmodified. I will vote yes on the issue > assuming that the intent is clear, but I agree with Conrad > that final text changes should always be clear in the Revised > Text section. > > --Roger > > > > Subject: RE: Issues 9785 and 9794 on current ballot Date: Fri, 18 Aug 2006 09:03:32 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues 9785 and 9794 on current ballot Thread-Index: AcbClvqJ1xGEQqRRRoWjWO4Kv0oIjwAA9Kww From: "Chadburn, Fraser" To: "Branislav Selic" Cc: Does the IEEE standard take a very concrete view of a system? It might be worth clarifying that a system can be composed of both real & abstract entities, as some systems are purely procedural? Is the term component too strong, or am I entering into the shipping lane? . Fraser Product Manager ARTiSAN Software Tools Tel: +44(0)1242 229309 Fax: +44 (0)1242 229301 mailto:fraser.chadburn@artisansw.com http://www.artisansw.com "Real Expertise - Real Solutions - Real-time" -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 18 August 2006 08:22 To: Tim Weilkiens Cc: Burkhart Roger M; Friedenthal, Sanford; sysml-ftf@omg.org Subject: RE: Issues 9785 and 9794 on current ballot These too can be taken from IEEE 1471. "system: a collection of components required to accomplish a specific function or set of functions" (A subsystem is clearly a system that is a component of a greater system.) Based on my UML experience with the term, I think it owuld be dangerous to go beyond this. Too many conflicting definitions lead to terminology wars and OMG-like philosophical discussions about ships and identity. 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 "Tim Weilkiens" 08/18/2006 02:02 AM To "Friedenthal, Sanford" , "Burkhart Roger M" , cc Subject RE: Issues 9785 and 9794 on current ballot I think one major problem is that we have no clear definition of a system and subsystem. That makes it difficult. Different people have different views on these technical terms. Tim > -----Original Message----- > From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] > Sent: Thursday, August 17, 2006 9:35 PM > To: Burkhart Roger M; sysml-ftf@omg.org > Subject: RE: Issues 9785 and 9794 on current ballot > > Roger, SysML FTF > > I had some concern about modifying the defintion of view to > insert "or subsystem". I think a view of a "whole system" > already can accomodate a view of a "whole subsystem". The > view of the system is just defined from a subsystem > stakeholder perspective. If we want to generalize the > definition, I would think the term "whole system" should be > replaced by "whole model", but I didn't want to start down > that path at this time. > The current definition is pretty much the IEEE 1471 > definition. I recommend we stick with the current standard > definition for now. I registered a "No" vote to this proposed > resolution. > > Sandy > > -----Original Message----- > From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] > Sent: Thursday, August 17, 2006 11:45 AM > To: sysml-ftf@omg.org > Subject: Issues 9785 and 9794 on current ballot > > On Issue 9785, the initial Lockheed vote of "no" indicates, > "I prefer not to change the definition of view." The > proposed change is to insert "or subsystem" in the new > definition, "A view is a representation of a whole system or > subsystem from the perspective of a single viewpoint." > > Since I haven't seen any discussion on the mailing list about > the issue, I'll just note that a "whole system" could be > overly restrictive (not to mention undefined), and so I'll > vote yes in favor of the new text, which clarifies the > flexibility to use views at any level of a system in a system > hierarchy. > > On Issue 9794, Conrad wrote: > > > I didn't see any response to my comment on 9794, see below. > It seems > > like we shouldn't vote on it if the text changes are given in the > > resolution. Some of it is a submitter opinion, rather than a > > resolution. > > > One comment on the the ballot: > > > > - 9794 (Derived properties for requirements) > > > > The Revised Text section has discussion that should be in the > > Resolution seciton. The Revised Text section should give the > > exact change in the text. > > I don't know if this was already fixed, but the Revised Text > does now have only revised text, but the replacement text is > incomplete, ending with a fragment of the former text under > Constraints, with "[1] The type of return parameter". The > full text in the current spec is "[1] The type of return > parameter of the stereotyped model element must be VerdictKind. > (note this is consistent with the UML Testing Profile)." > > For clarity of instructions to the editors, I suggest that > Revised Text sections either completely replace a section, or > indicate when they're only referring to surrounding text > that's to be left unmodified. I will vote yes on the issue > assuming that the intent is clear, but I agree with Conrad > that final text changes should always be clear in the Revised > Text section. > > --Roger > > > > Date: Fri, 18 Aug 2006 08:46:49 -0400 From: "Friedenthal, Sanford" Subject: RE: Issues 9785 and 9794 on current ballot To: "Chadburn, Fraser" , Branislav Selic Cc: sysml-ftf@omg.org Thread-Topic: Issues 9785 and 9794 on current ballot Thread-Index: AcbClvqJ1xGEQqRRRoWjWO4Kv0oIjwAA9KwwAAoFC4A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 18 Aug 2006 12:46:50.0284 (UTC) FILETIME=[5FC62EC0:01C6C2C4] Fraser, FTF'rs There is not a formal definition of "system" or "subsystem" in SysML. These have always been terms that are used in many different ways that continue to evolve. One of the defintiions that is referred to on the INCOSE webiste (Fellows Consesus defintiion) is " Definition of a system A system is a construct or collection of different elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required to produce systems-level results. The results include system level qualities, properties, characteristics, functions, behavior and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected (Rechtin, 2000). One example area of disagreement is whether a system serves a purpose of one or more stakeholders. People raise the issue that this could exclude natural systems suchas the solar system from the defintiion. There are many other arguments over what a system is. However, in general, a system refers to a set of interacting elements that provide some unique behavior and/or properties. The term subsystem is also used in many different ways and is often distinct from the concept of a component. It usually implies a functional entity, but not always. I believe our approach in SysML to use the concept of a block that can represent any unit of structure, and can have behaviors and properties is solid. This enables the modeler to define their system, subsystems, and components in a way that works for them based on a common concept of a block. Sandy -------------------------------------------------------------------------------- From: Chadburn, Fraser [mailto:fraser.chadburn@ARTISANSW.com] Sent: Friday, August 18, 2006 4:04 AM To: Branislav Selic Cc: sysml-ftf@omg.org Subject: RE: Issues 9785 and 9794 on current ballot Does the IEEE standard take a very concrete view of a system? It might be worth clarifying that a system can be composed of both real & abstract entities, as some systems are purely procedural? Is the term component too strong, or am I entering into the shipping lane? . Fraser Product Manager ARTiSAN Software Tools Tel: +44(0)1242 229309 Fax: +44 (0)1242 229301 mailto:fraser.chadburn@artisansw.com http://www.artisansw.com "Real Expertise - Real Solutions - Real-time" -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 18 August 2006 08:22 To: Tim Weilkiens Cc: Burkhart Roger M; Friedenthal, Sanford; sysml-ftf@omg.org Subject: RE: Issues 9785 and 9794 on current ballot These too can be taken from IEEE 1471. "system: a collection of components required to accomplish a specific function or set of functions" (A subsystem is clearly a system that is a component of a greater system.) Based on my UML experience with the term, I think it owuld be dangerous to go beyond this. Too many conflicting definitions lead to terminology wars and OMG-like philosophical discussions about ships and identity. 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 "Tim Weilkiens" 08/18/2006 02:02 AM To "Friedenthal, Sanford" , "Burkhart Roger M" , cc Subject RE: Issues 9785 and 9794 on current ballot I think one major problem is that we have no clear definition of a system and subsystem. That makes it difficult. Different people have different views on these technical terms. Tim > -----Original Message----- > From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] > Sent: Thursday, August 17, 2006 9:35 PM > To: Burkhart Roger M; sysml-ftf@omg.org > Subject: RE: Issues 9785 and 9794 on current ballot > > Roger, SysML FTF > > I had some concern about modifying the defintion of view to > insert "or subsystem". I think a view of a "whole system" > already can accomodate a view of a "whole subsystem". The > view of the system is just defined from a subsystem > stakeholder perspective. If we want to generalize the > definition, I would think the term "whole system" should be > replaced by "whole model", but I didn't want to start down > that path at this time. > The current definition is pretty much the IEEE 1471 > definition. I recommend we stick with the current standard > definition for now. I registered a "No" vote to this proposed > resolution. > > Sandy > > -----Original Message----- > From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] > Sent: Thursday, August 17, 2006 11:45 AM > To: sysml-ftf@omg.org > Subject: Issues 9785 and 9794 on current ballot > > On Issue 9785, the initial Lockheed vote of "no" indicates, > "I prefer not to change the definition of view." The > proposed change is to insert "or subsystem" in the new > definition, "A view is a representation of a whole system or > subsystem from the perspective of a single viewpoint." > > Since I haven't seen any discussion on the mailing list about > the issue, I'll just note that a "whole system" could be > overly restrictive (not to mention undefined), and so I'll > vote yes in favor of the new text, which clarifies the > flexibility to use views at any level of a system in a system > hierarchy. > > On Issue 9794, Conrad wrote: > > > I didn't see any response to my comment on 9794, see below. > It seems > > like we shouldn't vote on it if the text changes are given in the > > resolution. Some of it is a submitter opinion, rather than a > > resolution. > > > One comment on the the ballot: > > > > - 9794 (Derived properties for requirements) > > > > The Revised Text section has discussion that should be in the > > Resolution seciton. The Revised Text section should give the > > exact change in the text. > > I don't know if this was already fixed, but the Revised Text > does now have only revised text, but the replacement text is > incomplete, ending with a fragment of the former text under > Constraints, with "[1] The type of return parameter". The > full text in the current spec is "[1] The type of return > parameter of the stereotyped model element must be VerdictKind. > (note this is consistent with the UML Testing Profile)." > > For clarity of instructions to the editors, I suggest that > Revised Text sections either completely replace a section, or > indicate when they're only referring to surrounding text > that's to be left unmodified. I will vote yes on the issue > assuming that the intent is clear, but I agree with Conrad > that final text changes should always be clear in the Revised > Text section. > > --Roger > > > > Subject: Re: Issues 9785 and 9794 on current ballot X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues 9785 and 9794 on current ballot Thread-Index: AcbCl4aQxZkvkfViQxOg9vBI6JP71gAWSsxb From: "Jack Low" To: , Cc: , , X-OriginalArrivalTime: 18 Aug 2006 18:04:09.0057 (UTC) FILETIME=[B3C46510:01C6C2F0] Date: Fri, 18 Aug 2006 14:04:07 -0400 X-Scan: Scanned for malicious content by netserver1.telelogicna.com X-Scan-Debug: 0 I tend to agree with Bran. Using anything but a broad definition would unecessarily constrain usage. I also liked Sandys definition but would rather we leave well enough alone. -------------------------- Jack Low Telelogic -----Original Message----- From: Branislav Selic To: Tim Weilkiens CC: Burkhart Roger M ; Friedenthal, Sanford ; sysml-ftf@omg.org Sent: Fri Aug 18 03:21:44 2006 Subject: RE: Issues 9785 and 9794 on current ballot These too can be taken from IEEE 1471. "system: a collection of components required to accomplish a specific function or set of functions" (A subsystem is clearly a system that is a component of a greater system.) Based on my UML experience with the term, I think it owuld be dangerous to go beyond this. Too many conflicting definitions lead to terminology wars and OMG-like philosophical discussions about ships and identity. 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 "Tim Weilkiens" 08/18/2006 02:02 AM To "Friedenthal, Sanford" , "Burkhart Roger M" , cc Subject RE: Issues 9785 and 9794 on current ballot I think one major problem is that we have no clear definition of a system and subsystem. That makes it difficult. Different people have different views on these technical terms. Tim > -----Original Message----- > From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] > Sent: Thursday, August 17, 2006 9:35 PM > To: Burkhart Roger M; sysml-ftf@omg.org > Subject: RE: Issues 9785 and 9794 on current ballot > > Roger, SysML FTF > > I had some concern about modifying the defintion of view to > insert "or subsystem". I think a view of a "whole system" > already can accomodate a view of a "whole subsystem". The > view of the system is just defined from a subsystem > stakeholder perspective. If we want to generalize the > definition, I would think the term "whole system" should be > replaced by "whole model", but I didn't want to start down > that path at this time. > The current definition is pretty much the IEEE 1471 > definition. I recommend we stick with the current standard > definition for now. I registered a "No" vote to this proposed > resolution. > > Sandy > > -----Original Message----- > From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] > Sent: Thursday, August 17, 2006 11:45 AM > To: sysml-ftf@omg.org > Subject: Issues 9785 and 9794 on current ballot > > On Issue 9785, the initial Lockheed vote of "no" indicates, > "I prefer not to change the definition of view." The > proposed change is to insert "or subsystem" in the new > definition, "A view is a representation of a whole system or > subsystem from the perspective of a single viewpoint." > > Since I haven't seen any discussion on the mailing list about > the issue, I'll just note that a "whole system" could be > overly restrictive (not to mention undefined), and so I'll > vote yes in favor of the new text, which clarifies the > flexibility to use views at any level of a system in a system > hierarchy. > > On Issue 9794, Conrad wrote: > > > I didn't see any response to my comment on 9794, see below. > It seems > > like we shouldn't vote on it if the text changes are given in the > > resolution. Some of it is a submitter opinion, rather than a > > resolution. > > > One comment on the the ballot: > > > > - 9794 (Derived properties for requirements) > > > > The Revised Text section has discussion that should be in the > > Resolution seciton. The Revised Text section should give the > > exact change in the text. > > I don't know if this was already fixed, but the Revised Text > does now have only revised text, but the replacement text is > incomplete, ending with a fragment of the former text under > Constraints, with "[1] The type of return parameter". The > full text in the current spec is "[1] The type of return > parameter of the stereotyped model element must be VerdictKind. > (note this is consistent with the UML Testing Profile)." > > For clarity of instructions to the editors, I suggest that > Revised Text sections either completely replace a section, or > indicate when they're only referring to surrounding text > that's to be left unmodified. I will vote yes on the issue > assuming that the intent is clear, but I agree with Conrad > that final text changes should always be clear in the Revised > Text section. > > --Roger > > > > To: "Chadburn, Fraser" Cc: sysml-ftf@omg.org Subject: RE: Issues 9785 and 9794 on current ballot X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 From: Branislav Selic Date: Mon, 21 Aug 2006 04:04:56 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 08/21/2006 04:04:58, Serialize complete at 08/21/2006 04:04:58 Without meaning to offend anyone, this is precisely the kind of subtlety and related discussions that I think we should try to avoid. The IEEE standard definition is very general and very broad, which is why it is useful. Any attempts to make it more precise will undoubtedly prove controversial and will lead us down a rathole. 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 "Chadburn, Fraser" 08/18/2006 04:03 AM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: Issues 9785 and 9794 on current ballot Does the IEEE standard take a very concrete view of a system? It might be worth clarifying that a system can be composed of both real & abstract entities, as some systems are purely procedural? Is the term component too strong, or am I entering into the shipping lane? . Fraser Product Manager ARTiSAN Software Tools Tel: +44(0)1242 229309 Fax: +44 (0)1242 229301 mailto:fraser.chadburn@artisansw.com http://www.artisansw.com "Real Expertise - Real Solutions - Real-time" -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 18 August 2006 08:22 To: Tim Weilkiens Cc: Burkhart Roger M; Friedenthal, Sanford; sysml-ftf@omg.org Subject: RE: Issues 9785 and 9794 on current ballot These too can be taken from IEEE 1471. "system: a collection of components required to accomplish a specific function or set of functions" (A subsystem is clearly a system that is a component of a greater system.) Based on my UML experience with the term, I think it owuld be dangerous to go beyond this. Too many conflicting definitions lead to terminology wars and OMG-like philosophical discussions about ships and identity. 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 "Tim Weilkiens" 08/18/2006 02:02 AM To "Friedenthal, Sanford" , "Burkhart Roger M" , cc Subject RE: Issues 9785 and 9794 on current ballot I think one major problem is that we have no clear definition of a system and subsystem. That makes it difficult. Different people have different views on these technical terms. Tim > -----Original Message----- > From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] > Sent: Thursday, August 17, 2006 9:35 PM > To: Burkhart Roger M; sysml-ftf@omg.org > Subject: RE: Issues 9785 and 9794 on current ballot > > Roger, SysML FTF > > I had some concern about modifying the defintion of view to > insert "or subsystem". I think a view of a "whole system" > already can accomodate a view of a "whole subsystem". The > view of the system is just defined from a subsystem > stakeholder perspective. If we want to generalize the > definition, I would think the term "whole system" should be > replaced by "whole model", but I didn't want to start down > that path at this time. > The current definition is pretty much the IEEE 1471 > definition. I recommend we stick with the current standard > definition for now. I registered a "No" vote to this proposed > resolution. > > Sandy > > -----Original Message----- > From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] > Sent: Thursday, August 17, 2006 11:45 AM > To: sysml-ftf@omg.org > Subject: Issues 9785 and 9794 on current ballot > > On Issue 9785, the initial Lockheed vote of "no" indicates, > "I prefer not to change the definition of view." The > proposed change is to insert "or subsystem" in the new > definition, "A view is a representation of a whole system or > subsystem from the perspective of a single viewpoint." > > Since I haven't seen any discussion on the mailing list about > the issue, I'll just note that a "whole system" could be > overly restrictive (not to mention undefined), and so I'll > vote yes in favor of the new text, which clarifies the > flexibility to use views at any level of a system in a system > hierarchy. > > On Issue 9794, Conrad wrote: > > > I didn't see any response to my comment on 9794, see below. > It seems > > like we shouldn't vote on it if the text changes are given in the > > resolution. Some of it is a submitter opinion, rather than a > > resolution. > > > One comment on the the ballot: > > > > - 9794 (Derived properties for requirements) > > > > The Revised Text section has discussion that should be in the > > Resolution seciton. The Revised Text section should give the > > exact change in the text. > > I don't know if this was already fixed, but the Revised Text > does now have only revised text, but the replacement text is > incomplete, ending with a fragment of the former text under > Constraints, with "[1] The type of return parameter". The > full text in the current spec is "[1] The type of return > parameter of the stereotyped model element must be VerdictKind. > (note this is consistent with the UML Testing Profile)." > > For clarity of instructions to the editors, I suggest that > Revised Text sections either completely replace a section, or > indicate when they're only referring to surrounding text > that's to be left unmodified. I will vote yes on the issue > assuming that the intent is clear, but I agree with Conrad > that final text changes should always be clear in the Revised > Text section. > > --Roger > > > > Subject: RE: Issues 9785 and 9794 on current ballot Date: Mon, 21 Aug 2006 09:38:30 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues 9785 and 9794 on current ballot Thread-Index: AcbClvqJ1xGEQqRRRoWjWO4Kv0oIjwAA9KwwAAoFC4AAjln7UA== From: "Chadburn, Fraser" To: "Friedenthal, Sanford" , "Branislav Selic" Cc: In the interests of progress, it all sounds jolly fine to me. Remind me of the quote from that German bloke, "what we cannot speak we must pass over in silence.... . Fraser -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: 18 August 2006 13:47 To: Chadburn, Fraser; Branislav Selic Cc: sysml-ftf@omg.org Subject: RE: Issues 9785 and 9794 on current ballot Fraser, FTF'rs There is not a formal definition of "system" or "subsystem" in SysML. These have always been terms that are used in many different ways that continue to evolve. One of the defintiions that is referred to on the INCOSE webiste (Fellows Consesus defintiion) is " Definition of a system A system is a construct or collection of different elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required to produce systems-level results. The results include system level qualities, properties, characteristics, functions, behavior and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected (Rechtin, 2000). One example area of disagreement is whether a system serves a purpose of one or more stakeholders. People raise the issue that this could exclude natural systems suchas the solar system from the defintiion. There are many other arguments over what a system is. However, in general, a system refers to a set of interacting elements that provide some unique behavior and/or properties. The term subsystem is also used in many different ways and is often distinct from the concept of a component. It usually implies a functional entity, but not always. I believe our approach in SysML to use the concept of a block that can represent any unit of structure, and can have behaviors and properties is solid. This enables the modeler to define their system, subsystems, and components in a way that works for them based on a common concept of a block. Sandy -------------------------------------------------------------------------------- From: Chadburn, Fraser [mailto:fraser.chadburn@ARTISANSW.com] Sent: Friday, August 18, 2006 4:04 AM To: Branislav Selic Cc: sysml-ftf@omg.org Subject: RE: Issues 9785 and 9794 on current ballot Does the IEEE standard take a very concrete view of a system? It might be worth clarifying that a system can be composed of both real & abstract entities, as some systems are purely procedural? Is the term component too strong, or am I entering into the shipping lane? . Fraser Product Manager ARTiSAN Software Tools Tel: +44(0)1242 229309 Fax: +44 (0)1242 229301 mailto:fraser.chadburn@artisansw.com http://www.artisansw.com "Real Expertise - Real Solutions - Real-time" -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 18 August 2006 08:22 To: Tim Weilkiens Cc: Burkhart Roger M; Friedenthal, Sanford; sysml-ftf@omg.org Subject: RE: Issues 9785 and 9794 on current ballot These too can be taken from IEEE 1471. "system: a collection of components required to accomplish a specific function or set of functions" (A subsystem is clearly a system that is a component of a greater system.) Based on my UML experience with the term, I think it owuld be dangerous to go beyond this. Too many conflicting definitions lead to terminology wars and OMG-like philosophical discussions about ships and identity. 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 "Tim Weilkiens" 08/18/2006 02:02 AM To "Friedenthal, Sanford" , "Burkhart Roger M" , cc Subject RE: Issues 9785 and 9794 on current ballot I think one major problem is that we have no clear definition of a system and subsystem. That makes it difficult. Different people have different views on these technical terms. Tim > -----Original Message----- > From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] > Sent: Thursday, August 17, 2006 9:35 PM > To: Burkhart Roger M; sysml-ftf@omg.org > Subject: RE: Issues 9785 and 9794 on current ballot > > Roger, SysML FTF > > I had some concern about modifying the defintion of view to > insert "or subsystem". I think a view of a "whole system" > already can accomodate a view of a "whole subsystem". The > view of the system is just defined from a subsystem > stakeholder perspective. If we want to generalize the > definition, I would think the term "whole system" should be > replaced by "whole model", but I didn't want to start down > that path at this time. > The current definition is pretty much the IEEE 1471 > definition. I recommend we stick with the current standard > definition for now. I registered a "No" vote to this proposed > resolution. > > Sandy > > -----Original Message----- > From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] > Sent: Thursday, August 17, 2006 11:45 AM > To: sysml-ftf@omg.org > Subject: Issues 9785 and 9794 on current ballot > > On Issue 9785, the initial Lockheed vote of "no" indicates, > "I prefer not to change the definition of view." The > proposed change is to insert "or subsystem" in the new > definition, "A view is a representation of a whole system or > subsystem from the perspective of a single viewpoint." > > Since I haven't seen any discussion on the mailing list about > the issue, I'll just note that a "whole system" could be > overly restrictive (not to mention undefined), and so I'll > vote yes in favor of the new text, which clarifies the > flexibility to use views at any level of a system in a system > hierarchy. > > On Issue 9794, Conrad wrote: > > > I didn't see any response to my comment on 9794, see below. > It seems > > like we shouldn't vote on it if the text changes are given in the > > resolution. Some of it is a submitter opinion, rather than a > > resolution. > > > One comment on the the ballot: > > > > - 9794 (Derived properties for requirements) > > > > The Revised Text section has discussion that should be in the > > Resolution seciton. The Revised Text section should give the > > exact change in the text. > > I don't know if this was already fixed, but the Revised Text > does now have only revised text, but the replacement text is > incomplete, ending with a fragment of the former text under > Constraints, with "[1] The type of return parameter". The > full text in the current spec is "[1] The type of return > parameter of the stereotyped model element must be VerdictKind. > (note this is consistent with the UML Testing Profile)." > > For clarity of instructions to the editors, I suggest that > Revised Text sections either completely replace a section, or > indicate when they're only referring to surrounding text > that's to be left unmodified. I will vote yes on the issue > assuming that the intent is clear, but I agree with Conrad > that final text changes should always be clear in the Revised > Text section. > > --Roger > > > > Subject: RE: Issues 9785 and 9794 on current ballot Date: Mon, 21 Aug 2006 19:55:16 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues 9785 and 9794 on current ballot thread-index: AcbClvqJ1xGEQqRRRoWjWO4Kv0oIjwAA9KwwAKXRRwA= From: "Tim Weilkiens" To: "Chadburn, Fraser" , "Branislav Selic" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k7LHtLxB028273 Do you propose to write "a view is a reprenstation of a component"? I won't do that since the term "component" is overloaded in several disciplines. It's not a good term for a interdisciplinary language. Tim > -----Original Message----- > From: Chadburn, Fraser [mailto:fraser.chadburn@ARTISANSW.com] > Sent: Friday, August 18, 2006 10:04 AM > To: Branislav Selic > Cc: sysml-ftf@omg.org > Subject: RE: Issues 9785 and 9794 on current ballot > > Does the IEEE standard take a very concrete view of a system? > It might be worth clarifying that a system can be composed of > both real & abstract entities, as some systems are purely > procedural? Is the term component too strong, or am I > entering into the shipping lane? > > > > ... Fraser > > > > Product Manager > > > > ARTiSAN Software Tools > > > > Tel: +44(0)1242 229309 Fax: +44 (0)1242 229301 > > mailto:fraser.chadburn@artisansw.com > > > http://www.artisansw.com > > > > "Real Expertise - Real Solutions - Real-time" > > > > ________________________________ > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: 18 August 2006 08:22 > To: Tim Weilkiens > Cc: Burkhart Roger M; Friedenthal, Sanford; sysml-ftf@omg.org > Subject: RE: Issues 9785 and 9794 on current ballot > > > > > These too can be taken from IEEE 1471. > > "system: a collection of components required to accomplish a > specific function or set of functions" > (A subsystem is clearly a system that is a component of a > greater system.) > > Based on my UML experience with the term, I think it owuld be > dangerous to go beyond this. Too many conflicting definitions > lead to terminology wars and OMG-like philosophical > discussions about ships and identity. > > 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 > > > > "Tim Weilkiens" > > 08/18/2006 02:02 AM > > To > > "Friedenthal, Sanford" , > "Burkhart Roger M" , > > > cc > > > > Subject > > RE: Issues 9785 and 9794 on current ballot > > > > > > > > > > > I think one major problem is that we have no clear definition > of a system and subsystem. That makes it difficult. Different > people have different views on these technical terms. > > Tim > > > -----Original Message----- > > From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] > > Sent: Thursday, August 17, 2006 9:35 PM > > To: Burkhart Roger M; sysml-ftf@omg.org > > Subject: RE: Issues 9785 and 9794 on current ballot > > > > Roger, SysML FTF > > > > I had some concern about modifying the defintion of view to > insert "or > > subsystem". I think a view of a "whole system" > > already can accomodate a view of a "whole subsystem". The > view of the > > system is just defined from a subsystem stakeholder > perspective. If we > > want to generalize the definition, I would think the term "whole > > system" should be replaced by "whole model", but I didn't want to > > start down that path at this time. > > The current definition is pretty much the IEEE 1471 definition. I > > recommend we stick with the current standard definition for now. I > > registered a "No" vote to this proposed resolution. > > > > Sandy > > > > -----Original Message----- > > From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] > > Sent: Thursday, August 17, 2006 11:45 AM > > To: sysml-ftf@omg.org > > Subject: Issues 9785 and 9794 on current ballot > > > > On Issue 9785, the initial Lockheed vote of "no" indicates, > "I prefer > > not to change the definition of view." The proposed change is to > > insert "or subsystem" in the new definition, "A view is a > > representation of a whole system or subsystem from the > perspective of > > a single viewpoint." > > > > Since I haven't seen any discussion on the mailing list about the > > issue, I'll just note that a "whole system" could be overly > > restrictive (not to mention undefined), and so I'll vote > yes in favor > > of the new text, which clarifies the flexibility to use > views at any > > level of a system in a system hierarchy. > > > > On Issue 9794, Conrad wrote: > > > > > I didn't see any response to my comment on 9794, see below. > > It seems > > > like we shouldn't vote on it if the text changes are given in the > > > resolution. Some of it is a submitter opinion, rather than a > > > resolution. > > > > > One comment on the the ballot: > > > > > > - 9794 (Derived properties for requirements) > > > > > > The Revised Text section has discussion that should > be in the > > > Resolution seciton. The Revised Text section > should give the > > > exact change in the text. > > > > I don't know if this was already fixed, but the Revised > Text does now > > have only revised text, but the replacement text is > incomplete, ending > > with a fragment of the former text under Constraints, with "[1] The > > type of return parameter". The full text in the current > spec is "[1] > > The type of return parameter of the stereotyped model > element must be > > VerdictKind. > > (note this is consistent with the UML Testing Profile)." > > > > For clarity of instructions to the editors, I suggest that Revised > > Text sections either completely replace a section, or indicate when > > they're only referring to surrounding text that's to be left > > unmodified. I will vote yes on the issue assuming that the > intent is > > clear, but I agree with Conrad that final text changes > should always > > be clear in the Revised Text section. > > > > --Roger > > > > > > > > > > Subject: RE: Issues 9785 and 9794 on current ballot Date: Mon, 21 Aug 2006 19:55:08 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues 9785 and 9794 on current ballot thread-index: AcbClvqJ1xGEQqRRRoWjWO4Kv0oIjwAA9KwwAAoFC4AAm/YM8A== From: "Tim Weilkiens" To: "Friedenthal, Sanford" , "Chadburn, Fraser" , "Branislav Selic" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k7LHtNB6028271 > I believe our approach in SysML to use the concept of a block > that can represent any unit of structure, and can have > behaviors and properties is solid. This enables the modeler > to define their system, subsystems, and components in a way > that works for them based on a common concept of a block. Do you mean that all concepts (system, subsystem, components) are covered by the block element? I agree. If the modeler decides in his approach what a system/subsystem is, why should we restrict him in the usage of the view? You can convince me, but at the moment I agree with Roger: > > I'll just note that a "whole system" could be > > overly restrictive (not to mention undefined), and so I'll > > vote yes in favor of the new text, which clarifies the > > flexibility to use views at any level of a system in a system > > hierarchy. Tim > -----Original Message----- > From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] > Sent: Friday, August 18, 2006 2:47 PM > To: Chadburn, Fraser; Branislav Selic > Cc: sysml-ftf@omg.org > Subject: RE: Issues 9785 and 9794 on current ballot > > Fraser, FTF'rs > > There is not a formal definition of "system" or "subsystem" > in SysML. These have always been terms that are used in many > different ways that continue to evolve. One of the > defintiions that is referred to on the INCOSE webiste > (Fellows Consesus defintiion) is " > Definition of a system > > A system is a construct or collection of different elements > that together produce results not obtainable by the elements > alone. The elements, or parts, can include people, hardware, > software, facilities, policies, and documents; that is, all > things required to produce systems-level results. The results > include system level qualities, properties, characteristics, > functions, behavior and performance. The value added by the > system as a whole, beyond that contributed independently by > the parts, is primarily created by the relationship among the > parts; that is, how they are interconnected (Rechtin, 2000). > > > One example area of disagreement is whether a system serves a > purpose of one or more stakeholders. People raise the issue > that this could exclude natural systems suchas the solar > system from the defintiion. There are many other arguments > over what a system is. However, in general, a system refers > to a set of interacting elements that provide some unique > behavior and/or properties. The term subsystem is also used > in many different ways and is often distinct from the concept > of a component. It usually implies a functional entity, but > not always. > > I believe our approach in SysML to use the concept of a block > that can represent any unit of structure, and can have > behaviors and properties is solid. This enables the modeler > to define their system, subsystems, and components in a way > that works for them based on a common concept of a block. > > Sandy > > ________________________________ > > From: Chadburn, Fraser [mailto:fraser.chadburn@ARTISANSW.com] > Sent: Friday, August 18, 2006 4:04 AM > To: Branislav Selic > Cc: sysml-ftf@omg.org > Subject: RE: Issues 9785 and 9794 on current ballot > > > > Does the IEEE standard take a very concrete view of a system? > It might be worth clarifying that a system can be composed of > both real & abstract entities, as some systems are purely > procedural? Is the term component too strong, or am I > entering into the shipping lane? > > > > ... Fraser > > > > Product Manager > > > > ARTiSAN Software Tools > > > > Tel: +44(0)1242 229309 Fax: +44 (0)1242 229301 > > mailto:fraser.chadburn@artisansw.com > > > http://www.artisansw.com > > > > "Real Expertise - Real Solutions - Real-time" > > > > ________________________________ > > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: 18 August 2006 08:22 > To: Tim Weilkiens > Cc: Burkhart Roger M; Friedenthal, Sanford; sysml-ftf@omg.org > Subject: RE: Issues 9785 and 9794 on current ballot > > > > > These too can be taken from IEEE 1471. > > "system: a collection of components required to accomplish a > specific function or set of functions" > (A subsystem is clearly a system that is a component of a > greater system.) > > Based on my UML experience with the term, I think it owuld be > dangerous to go beyond this. Too many conflicting definitions > lead to terminology wars and OMG-like philosophical > discussions about ships and identity. > > 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 > > > > "Tim Weilkiens" > > 08/18/2006 02:02 AM > > To > > "Friedenthal, Sanford" , > "Burkhart Roger M" , > > > cc > > > > Subject > > RE: Issues 9785 and 9794 on current ballot > > > > > > > > > > > I think one major problem is that we have no clear definition > of a system and subsystem. That makes it difficult. Different people > have different views on these technical terms. > > Tim > > > -----Original Message----- > > From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] > > Sent: Thursday, August 17, 2006 9:35 PM > > To: Burkhart Roger M; sysml-ftf@omg.org > > Subject: RE: Issues 9785 and 9794 on current ballot > > > > Roger, SysML FTF > > > > I had some concern about modifying the defintion of view to > > insert "or subsystem". I think a view of a "whole system" > > already can accomodate a view of a "whole subsystem". The > > view of the system is just defined from a subsystem > > stakeholder perspective. If we want to generalize the > > definition, I would think the term "whole system" should be > > replaced by "whole model", but I didn't want to start down > > that path at this time. > > The current definition is pretty much the IEEE 1471 > > definition. I recommend we stick with the current standard > > definition for now. I registered a "No" vote to this proposed > > resolution. > > > > Sandy > > > > -----Original Message----- > > From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] > > Sent: Thursday, August 17, 2006 11:45 AM > > To: sysml-ftf@omg.org > > Subject: Issues 9785 and 9794 on current ballot > > > > On Issue 9785, the initial Lockheed vote of "no" indicates, > > "I prefer not to change the definition of view." The > > proposed change is to insert "or subsystem" in the new > > definition, "A view is a representation of a whole system or > > subsystem from the perspective of a single viewpoint." > > > > Since I haven't seen any discussion on the mailing list about > > the issue, I'll just note that a "whole system" could be > > overly restrictive (not to mention undefined), and so I'll > > vote yes in favor of the new text, which clarifies the > > flexibility to use views at any level of a system in a system > > hierarchy. > > > > On Issue 9794, Conrad wrote: > > > > > I didn't see any response to my comment on 9794, see below. > > It seems > > > like we shouldn't vote on it if the text changes are given in the > > > resolution. Some of it is a submitter opinion, rather than a > > > resolution. > > > > > One comment on the the ballot: > > > > > > - 9794 (Derived properties for requirements) > > > > > > The Revised Text section has discussion that should > be in the > > > Resolution seciton. The Revised Text section > should give the > > > exact change in the text. > > > > I don't know if this was already fixed, but the Revised Text > > does now have only revised text, but the replacement text is > > incomplete, ending with a fragment of the former text under > > Constraints, with "[1] The type of return parameter". The > > full text in the current spec is "[1] The type of return > > parameter of the stereotyped model element must be VerdictKind. > > (note this is consistent with the UML Testing Profile)." > > > > For clarity of instructions to the editors, I suggest that > > Revised Text sections either completely replace a section, or > > indicate when they're only referring to surrounding text > > that's to be left unmodified. I will vote yes on the issue > > assuming that the intent is clear, but I agree with Conrad > > that final text changes should always be clear in the Revised > > Text section. > > > > --Roger > > > > > > > > >