Issue 18653: View and Viewpoint Property Limitations (from Issue 18391 a) and f)) (sysml-rtf) Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: Source: Jet Propulsion Lab (Chris Delp – Christopher.L.Delp@jpl.nasa.gov) INCOSE (Sanford A. Friedenthal – safriedenthal@gmail.com) Summary: This issue represents issues a) and f) from Issue 18391 – View and Viewpoint Limitations in Support of Auto-View Generation. An important capability of a model based approach is the ability to automatically generate Views of the information from the model to support specific stakeholder Viewpoints. These Views may include the presentation of the modeling information in multiple forms such as diagrams, tables, or entire documents captured in different formats (e.g., MS Word, html, ppt, video). The View and Viewpoint constructs in SysML were included to aid in the automatic generation of Views, by enabling the specification of the View information and its presentation to address the stakeholder concerns. The View generation is generally implemented by other rendering applications. At the SE DSIG meeting on June 18, 2012 in Cambridge, several individuals presented and demonstrated common practices for View generation from a model that are providing value to end users. The presentations are available from the Cambridge SE DSIG meeting page. The practices required the users and vendors to further extend View and Viewpoint in different ways to overcome inherent limitations in order to leverage their respective View generation capabilities. The lack of a standard approach limits interchange and requires that each user and vendor include their unique extensions. The specific limitations of View and Viewpoint are described below. For background, the Viewpoint and View descriptions in the SysML specification v1.3 currently read as follows: Viewpoint: A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases. View: A View is a representation of a whole system or subsystem from the perspective of a single viewpoint. Views are allowed to import other elements including other packages and other views that conform to the viewpoint. Based on the above descriptions, the Viewpoint specifies how to construct a View, and the View is a representation that conforms to this specification. Some of the limitations that have been identified include the following: a) Viewpoint method limitations. The current Viewpoint contains a property called method that is typed by a text string (methods:String[*]). In order to auto-generate Views, the Viewpoint should include provisions to more formally specify ‘the conventions and rules for constructing and using a view’. This may include specifying executable methods to query the model that extract the desired information from the model, and present the information to the stakeholders. Viewpoint methods must be capable of specifying the scope of the information to be rendered, how the information should be rendered, as well as other methods related to checking, validating, or otherwise analyzing the information. The scope of the information may include information from other data sources not contained directly in the model. (Note: Standard methods may be captured in a method library that specify how to query, transform, analyze, present, and render data.) b) Viewpoint property limitations. Some of the Viewpoint properties, such as stakeholder, concern, and modeling language are currently typed as text strings, and may be better represented by other types. For cases where these elements are common among different viewpoints, there is no way to model these elements or the relationships between them. In a large-scale model, this becomes very difficult to scale. In particular, it is difficult to reuse the model elements such as stakeholder across different viewpoints, and it is difficult to perform automated checking of the viewpoints based on these viewpoint properties. The viewpoint properties should be typed by model elements that enable this reuse and checking. Resolution: Revised Text: Actions taken: April 11, 2013: received issue Discussion: End of Annotations:===== eceived: by 10.49.76.101 with SMTP id j5mr9493348qew.34.1365706407390; Thu, 11 Apr 2013 11:53:27 -0700 (PDT) Reply-To: From: "Sanford Friedenthal" To: "'Juergen Boldt'" Subject: Issue - View and Viewpoint Limitations a) and f) from Issue 18391 Date: Thu, 11 Apr 2013 14:53:03 -0400 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac425cucwrFwyiU9TdafTOvS4wWRGA== X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAgzCY6MdeUK9 X-Brightmail-Tracker: AAAAAA== Juergen Can you file the following issue, which is a sub issue of Issue 18391, which I previously filed. I will file another sub-issue at a later date, but this is the part we are focused on resolving at this time. Thank you. Regards, Sandy Issue: View and Viewpoint Property Limitations (from Issue 18391 a) and f)) Source: Jet Propulsion Lab (Chris Delp . Christopher.L.Delp@jpl.nasa.gov) INCOSE (Sanford A. Friedenthal . safriedenthal@gmail.com) Summary: This issue represents issues a) and f) from Issue 18391 . View and Viewpoint Limitations in Support of Auto-View Generation. An important capability of a model based approach is the ability to automatically generate Views of the information from the model to support specific stakeholder Viewpoints. These Views may include the presentation of the modeling information in multiple forms such as diagrams, tables, or entire documents captured in different formats (e.g., MS Word, html, ppt, video). The View and Viewpoint constructs in SysML were included to aid in the automatic generation of Views, by enabling the specification of the View information and its presentation to address the stakeholder concerns. The View generation is generally implemented by other rendering applications. At the SE DSIG meeting on June 18, 2012 in Cambridge, several individuals presented and demonstrated common practices for View generation from a model that are providing value to end users. The presentations are available from the Cambridge SE DSIG meeting page. The practices required the users and vendors to further extend View and Viewpoint in different ways to overcome inherent limitations in order to leverage their respective View generation capabilities. The lack of a standard approach limits interchange and requires that each user and vendor include their unique extensions. The specific limitations of View and Viewpoint are described below. For background, the Viewpoint and View descriptions in the SysML specification v1.3 currently read as follows: Viewpoint: A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases. View: A View is a representation of a whole system or subsystem from the perspective of a single viewpoint. Views are allowed to import other elements including other packages and other views that conform to the viewpoint. Based on the above descriptions, the Viewpoint specifies how to construct a View, and the View is a representation that conforms to this specification. Some of the limitations that have been identified include the following: a) Viewpoint method limitations. The current Viewpoint contains a property called method that is typed by a text string (methods:String[*]). In order to auto-generate Views, the Viewpoint should include provisions to more formally specify .the conventions and rules for constructing and using a view.. This may include specifying executable methods to query the model that extract the desired information from the model, and present the information to the stakeholders. Viewpoint methods must be capable of specifying the scope of the information to be rendered, how the information should be rendered, as well as other methods related to checking, validating, or otherwise analyzing the information. The scope of the information may include information from other data sources not contained directly in the model. (Note: Standard methods may be captured in a method library that specify how to query, transform, analyze, present, and render data.) b) Viewpoint property limitations. Some of the Viewpoint properties, such as stakeholder, concern, and modeling language are currently typed as text strings, and may be better represented by other types. For cases where these elements are common among different viewpoints, there is no way to model these elements or the relationships between them. In a large-scale model, this becomes very difficult to scale. In particular, it is difficult to reuse the model elements such as stakeholder across different viewpoints, and it is difficult to perform automated checking of the viewpoints based on these viewpoint properties. The viewpoint properties should be typed by model elements that enable this reuse and checking. From: Phil Astle To: "'Chonoles, Michael J'" , "BurkhartRogerM@johndeere.com" , "sysml-rtf@omg.org" CC: "Bock, Conrad" Subject: RE: draft ballot 5 available for discussion through Friday, May 10, 2013 Thread-Topic: draft ballot 5 available for discussion through Friday, May 10, 2013 Thread-Index: Ac5FD/XWL6VnrFFtRUSfls9Q+jRitwACpDwQABkD57A= Date: Tue, 30 Apr 2013 08:53:04 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.1.39] x-esetresult: clean, is OK x-esetid: B9C0C5236DF93032EC879E X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== 18653 Further to Michael.s comments, the constraints section for Stakeholder (7.3.2.4) doesn.t make sense to me either. It states: [1] Stereotype is applied to any typed element that is typed by the classifier with the applied stereotype. However, Stakeholder is shown as only extending Class so how does that constraint work? Also, why would you want to apply the stereotype to .typed elements. anyway? Phil From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 29 April 2013 23:37 To: BurkhartRogerM@johndeere.com; sysml-rtf@omg.org Cc: Bock, Conrad Subject: RE: draft ballot 5 available for discussion through Friday, May 10, 2013 18653 In the description for the resolution for 18653, there is a discussion of issue b, that has the new Stakeholder stereotype extending actor. However, in the Revised text, Stakeholder extends Class (though it uses the actor symbol (Table 7.1). This should be made consistent, with extending Actor being the preferred approach. In addition, I.d recommend, though minor, that the replacement Viewpoint have the list of attributes in the same order as the original, just so it.s easier to see what was done. 15075 a) If you showing {subset} and {refine on associations, you should probably also show {union} b) For the Block and ValueType, the operation2 has a return type of Types. While this is not impossible, because Types can be a verb, it.s a bit confusing, probably use Type2 c) I can.t remember, but I believe for property8, initializing property8: Boolean=true, should either be property8: Boolean=#true, or I think it.s now property8: Boolean=Boolean.true d) If we allow derived properties (which we should), we should show a property preceded by a /. 18435 a) Do we want to explicitly say that a unit can have more than one identical QuantityKind (as in l^2 for area)? Usually, an association is considered a set, here it is a bag. b) Why are symbols limited to 1 character? How do we handle mm? We can.t make mm a primary unit?. How about aA , the symbol for the abampere? In the Gaussian cgs unit, B and H are measured in Gs (Gauss) and Oe (Oerstead) c) QuanttiyKind can only part of 1 SystemOfQuantities. This seems wrong. For example, wouldn.t the amp and abamp, one is the SI unit and other being the emu-cgs unit of current, have the same quantity kind, current, but they might be in different SystemofQuantities. 12751 I.m still concerned that this approach (or really any approach I.ve seen) doesn.t really handle federated or distributed models very well. But I don.t see a solution. From: Burkhart Roger M [mailto:BurkhartRogerM@johndeere.com] Sent: Monday, April 29, 2013 3:30 PM To: sysml-rtf@omg.org Cc: Bock, Conrad Subject: EXTERNAL: draft ballot 5 available for discussion through Friday, May 10, 2013 A draft Ballot 5 is available for review and discussion on the SysML 1.4 RTF wiki at http://www.omg.org/members/sysml-rtf-wiki. (Click on the Ballot 5 link.) Ballot 5 will be open for discussion through Friday, May 10, 2013. The normal two-week voting period will then begin by Monday, May 13. Following are ballot review instructions which appear at the bottom of the ballot page: The review period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which will be frozen at the start of voting. If you have any concerns or questions about any of the proposed resolutions, please send a message to the sysml-rtf@omg.org mailing list. Review and discussion of this ballot will occur on regularly scheduled RTF telecons during the review period before voting begins. __________ Information from ESET Endpoint Antivirus, version of virus signature database 8280 (20130429) __________ The message was checked by ESET Endpoint Antivirus. http://www.eset.com __________ Information from ESET Endpoint Antivirus, version of virus signature database 8280 (20130429) __________ The message was checked by ESET Endpoint Antivirus. http://www.eset.com From: Tim Weilkiens To: Phil Astle , "'Chonoles, Michael J'" , "BurkhartRogerM@johndeere.com" , "sysml-rtf@omg.org" CC: "Bock, Conrad" Subject: RE: draft ballot 5 available for discussion through Friday, May 10, 2013 Thread-Topic: draft ballot 5 available for discussion through Friday, May 10, 2013 Thread-Index: Ac5FD/XWL6VnrFFtRUSfls9Q+jRitwACpDwQABkD57AAASiG4A== Date: Tue, 30 Apr 2013 13:17:14 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.19] X-XWALL-BCKS: auto X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh15Qr0delmo X-Brightmail-Tracker: AAAAAA== Hi Phil, As far as I know the notion behind the constraint is to use the stakeholder concepts in internal block diagrams. The part that is typed by a stakeholder should also have the stereotype. Tim From: Phil Astle [mailto:phil.astle@atego.com] Sent: Tuesday, April 30, 2013 10:53 AM To: 'Chonoles, Michael J'; BurkhartRogerM@johndeere.com; sysml-rtf@omg.org Cc: Bock, Conrad Subject: RE: draft ballot 5 available for discussion through Friday, May 10, 2013 18653 Further to Michael.s comments, the constraints section for Stakeholder (7.3.2.4) doesn.t make sense to me either. It states: [1] Stereotype is applied to any typed element that is typed by the classifier with the applied stereotype. However, Stakeholder is shown as only extending Class so how does that constraint work? Also, why would you want to apply the stereotype to .typed elements. anyway? Phil From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 29 April 2013 23:37 To: BurkhartRogerM@johndeere.com; sysml-rtf@omg.org Cc: Bock, Conrad Subject: RE: draft ballot 5 available for discussion through Friday, May 10, 2013 18653 In the description for the resolution for 18653, there is a discussion of issue b, that has the new Stakeholder stereotype extending actor. However, in the Revised text, Stakeholder extends Class (though it uses the actor symbol (Table 7.1). This should be made consistent, with extending Actor being the preferred approach. In addition, I.d recommend, though minor, that the replacement Viewpoint have the list of attributes in the same order as the original, just so it.s easier to see what was done. 15075 a) If you showing {subset} and {refine on associations, you should probably also show {union} b) For the Block and ValueType, the operation2 has a return type of Types. While this is not impossible, because Types can be a verb, it.s a bit confusing, probably use Type2 c) I can.t remember, but I believe for property8, initializing property8: Boolean=true, should either be property8: Boolean=#true, or I think it.s now property8: Boolean=Boolean.true d) If we allow derived properties (which we should), we should show a property preceded by a /. 18435 a) Do we want to explicitly say that a unit can have more than one identical QuantityKind (as in l^2 for area)? Usually, an association is considered a set, here it is a bag. b) Why are symbols limited to 1 character? How do we handle mm? We can.t make mm a primary unit?. How about aA , the symbol for the abampere? In the Gaussian cgs unit, B and H are measured in Gs (Gauss) and Oe (Oerstead) c) QuanttiyKind can only part of 1 SystemOfQuantities. This seems wrong. For example, wouldn.t the amp and abamp, one is the SI unit and other being the emu-cgs unit of current, have the same quantity kind, current, but they might be in different SystemofQuantities. 12751 I.m still concerned that this approach (or really any approach I.ve seen) doesn.t really handle federated or distributed models very well. But I don.t see a solution. From: Burkhart Roger M [mailto:BurkhartRogerM@johndeere.com] Sent: Monday, April 29, 2013 3:30 PM To: sysml-rtf@omg.org Cc: Bock, Conrad Subject: EXTERNAL: draft ballot 5 available for discussion through Friday, May 10, 2013 A draft Ballot 5 is available for review and discussion on the SysML 1.4 RTF wiki at http://www.omg.org/members/sysml-rtf-wiki. (Click on the Ballot 5 link.) Ballot 5 will be open for discussion through Friday, May 10, 2013. The normal two-week voting period will then begin by Monday, May 13. Following are ballot review instructions which appear at the bottom of the ballot page: The review period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which will be frozen at the start of voting. If you have any concerns or questions about any of the proposed resolutions, please send a message to the sysml-rtf@omg.org mailing list. Review and discussion of this ballot will occur on regularly scheduled RTF telecons during the review period before voting begins. __________ Information from ESET Endpoint Antivirus, version of virus signature database 8280 (20130429) __________ The message was checked by ESET Endpoint Antivirus. http://www.eset.com __________ Information from ESET Endpoint Antivirus, version of virus signature database 8280 (20130429) __________ The message was checked by ESET Endpoint Antivirus. http://www.eset.com From: Phil Astle To: "'Tim Weilkiens'" , "'Chonoles, Michael J'" , "BurkhartRogerM@johndeere.com" , "sysml-rtf@omg.org" CC: "Bock, Conrad" Subject: RE: draft ballot 5 available for discussion through Friday, May 10, 2013 Thread-Topic: draft ballot 5 available for discussion through Friday, May 10, 2013 Thread-Index: Ac5FD/XWL6VnrFFtRUSfls9Q+jRitwACpDwQABkD57AAASiG4AAJW5bA Date: Tue, 30 Apr 2013 13:53:29 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.1.39] x-esetresult: clean, is OK x-esetid: B9C0C5236DF93032EC879A X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== Hi Tim, Thanks for the feedback. Why would you need to stereotype the Property as a Stakeholder, to use it on an Internal Block Diagram? For example, you don.t stereotype Properties typed by a Block, with the Block stereotype. Also, would it be conceptually right . is a Property typed by a Stakeholder really a Stakeholder in its own right? Would you want to link a Property stereotyped as Stakeholder to a Viewpoint? If you do want a Property to act as a Stakeholder, the text and diagrams in the specification need to be updated to state this. Phil From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: 30 April 2013 14:17 To: Phil Astle; 'Chonoles, Michael J'; BurkhartRogerM@johndeere.com; sysml-rtf@omg.org Cc: Bock, Conrad Subject: RE: draft ballot 5 available for discussion through Friday, May 10, 2013 Hi Phil, As far as I know the notion behind the constraint is to use the stakeholder concepts in internal block diagrams. The part that is typed by a stakeholder should also have the stereotype. Tim From: Phil Astle [mailto:phil.astle@atego.com] Sent: Tuesday, April 30, 2013 10:53 AM To: 'Chonoles, Michael J'; BurkhartRogerM@johndeere.com; sysml-rtf@omg.org Cc: Bock, Conrad Subject: RE: draft ballot 5 available for discussion through Friday, May 10, 2013 18653 Further to Michael.s comments, the constraints section for Stakeholder (7.3.2.4) doesn.t make sense to me either. It states: [1] Stereotype is applied to any typed element that is typed by the classifier with the applied stereotype. However, Stakeholder is shown as only extending Class so how does that constraint work? Also, why would you want to apply the stereotype to .typed elements. anyway? Phil From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: 29 April 2013 23:37 To: BurkhartRogerM@johndeere.com; sysml-rtf@omg.org Cc: Bock, Conrad Subject: RE: draft ballot 5 available for discussion through Friday, May 10, 2013 18653 In the description for the resolution for 18653, there is a discussion of issue b, that has the new Stakeholder stereotype extending actor. However, in the Revised text, Stakeholder extends Class (though it uses the actor symbol (Table 7.1). This should be made consistent, with extending Actor being the preferred approach. In addition, I.d recommend, though minor, that the replacement Viewpoint have the list of attributes in the same order as the original, just so it.s easier to see what was done. 15075 a) If you showing {subset} and {refine on associations, you should probably also show {union} b) For the Block and ValueType, the operation2 has a return type of Types. While this is not impossible, because Types can be a verb, it.s a bit confusing, probably use Type2 c) I can.t remember, but I believe for property8, initializing property8: Boolean=true, should either be property8: Boolean=#true, or I think it.s now property8: Boolean=Boolean.true d) If we allow derived properties (which we should), we should show a property preceded by a /. 18435 a) Do we want to explicitly say that a unit can have more than one identical QuantityKind (as in l^2 for area)? Usually, an association is considered a set, here it is a bag. b) Why are symbols limited to 1 character? How do we handle mm? We can.t make mm a primary unit?. How about aA , the symbol for the abampere? In the Gaussian cgs unit, B and H are measured in Gs (Gauss) and Oe (Oerstead) c) QuanttiyKind can only part of 1 SystemOfQuantities. This seems wrong. For example, wouldn.t the amp and abamp, one is the SI unit and other being the emu-cgs unit of current, have the same quantity kind, current, but they might be in different SystemofQuantities. 12751 I.m still concerned that this approach (or really any approach I.ve seen) doesn.t really handle federated or distributed models very well. But I don.t see a solution. From: Burkhart Roger M [mailto:BurkhartRogerM@johndeere.com] Sent: Monday, April 29, 2013 3:30 PM To: sysml-rtf@omg.org Cc: Bock, Conrad Subject: EXTERNAL: draft ballot 5 available for discussion through Friday, May 10, 2013 A draft Ballot 5 is available for review and discussion on the SysML 1.4 RTF wiki at http://www.omg.org/members/sysml-rtf-wiki. (Click on the Ballot 5 link.) Ballot 5 will be open for discussion through Friday, May 10, 2013. The normal two-week voting period will then begin by Monday, May 13. Following are ballot review instructions which appear at the bottom of the ballot page: The review period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which will be frozen at the start of voting. If you have any concerns or questions about any of the proposed resolutions, please send a message to the sysml-rtf@omg.org mailing list. Review and discussion of this ballot will occur on regularly scheduled RTF telecons during the review period before voting begins. __________ Information from ESET Endpoint Antivirus, version of virus signature database 8280 (20130429) __________ The message was checked by ESET Endpoint Antivirus. http://www.eset.com __________ Information from ESET Endpoint Antivirus, version of virus signature database 8280 (20130429) __________ The message was checked by ESET Endpoint Antivirus. http://www.eset.com __________ Information from ESET Endpoint Antivirus, version of virus signature database 8282 (20130430) __________ The message was checked by ESET Endpoint Antivirus. http://www.eset.com __________ Information from ESET Endpoint Antivirus, version of virus signature database 8282 (20130430) __________ The message was checked by ESET Endpoint Antivirus. http://www.eset.com Subject: On issue 18653: View and Viewpoint Property Limitations X-KeepSent: 345409C5:08025B63-C2257B64:002ECBB2; type=4; name=$KeepSent To: sysml-rtf@omg.org X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Eldad Palachi Date: Tue, 7 May 2013 16:00:59 +0300 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.3FP2 ZX853FP2HF3|December 12, 2012) at 07/05/2013 16:00:48 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13050712-0542-0000-0000-0000052DE099 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Gentlemen, The change made to the method property of Viewpoint is confusing to me since I don't think see how people would actually use that to generate a View since it is not clear how to specify such methods and apply them on the model (I mean is this like the getAllocationFrom() method specified in OCL?) To me generating a View means selecting a subset of the model elements by some criteria. In Rhapsody, to support such a thing we use something called Query which is our tool specific way to select model elements without writing code. Queries can have nested queries to support complex selection of elements. Since generating a View is really selecting model elements - I think that a Query mechanism is more appropriate than just declaring that there is a method of doing that. Especially since in most cases our Add-on code is really external to the model and usually people don't model the add-ons they apply on models. Another option is to say that this method is really an OCL query on the model (or at least might be implemented as such) I realize it is very late but still we are in the discussion period and I would like to raise this point for discussion. Eldad P.S. Just a technicality, even if we stick with Behavior I think it should be method:Behavior[0,1] and not method:Behavior[*] since I don't see any point in having more than one behavior to select elements. From: "BERNARD, Yves" To: Eldad Palachi , "sysml-rtf@omg.org" Date: Tue, 7 May 2013 15:26:55 +0200 Subject: RE: On issue 18653: View and Viewpoint Property Limitations Thread-Topic: On issue 18653: View and Viewpoint Property Limitations Thread-Index: Ac5LIvWaMOF9r7wLTmGPRfOULz66MAAAuwag Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r47DRGm7020890 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Hi Eldad, I think that typing the method by Behavior is compatible with your implementation in Rhapsody since this behavior can be opaque. However, I support your point about the multiplicity of method: its upper bound shall be 1. Yves -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: mardi 7 mai 2013 15:01 To: sysml-rtf@omg.org Subject: On issue 18653: View and Viewpoint Property Limitations Gentlemen, The change made to the method property of Viewpoint is confusing to me since I don't think see how people would actually use that to generate a View since it is not clear how to specify such methods and apply them on the model (I mean is this like the getAllocationFrom() method specified in OCL?) To me generating a View means selecting a subset of the model elements by some criteria. In Rhapsody, to support such a thing we use something called Query which is our tool specific way to select model elements without writing code. Queries can have nested queries to support complex selection of elements. Since generating a View is really selecting model elements - I think that a Query mechanism is more appropriate than just declaring that there is a method of doing that. Especially since in most cases our Add-on code is really external to the model and usually people don't model the add-ons they apply on models. Another option is to say that this method is really an OCL query on the model (or at least might be implemented as such) I realize it is very late but still we are in the discussion period and I would like to raise this point for discussion. Eldad P.S. Just a technicality, even if we stick with Behavior I think it should be method:Behavior[0,1] and not method:Behavior[*] since I don't see any point in having more than one behavior to select elements. This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Tue, 7 May 2013 09:32:55 -0400 Subject: RE: On issue 18653: View and Viewpoint Property Limitations Thread-Topic: On issue 18653: View and Viewpoint Property Limitations Thread-Index: Ac5LIyHSgGvgA5gCToSh8EmnMiWdnwAA0C4Q Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Eldad, > Since generating a View is really selecting model elements - I think > that a Query mechanism is more appropriate than just declaring that > there is a method of doing that. Especially since in most cases our > Add-on code is really external to the model and usually people don't > model the add-ons they apply on models. You can use OpaqueBehavior, as Yves said, and if the query language is OCL (or other language supporting constraints on behavior results), the query can be written in a Constraint that is the postcondition of the behavior. Conrad X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on saturn.nomagic.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=4.1 tests=ALL_TRUSTED autolearn=disabled version=3.2.5 Date: Tue, 07 May 2013 07:35:39 -0600 From: Lonnie VanZandt Reply-To: lvanzandt@nomagic.com Organization: NoMagic, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 To: "BERNARD, Yves" CC: Eldad Palachi , "sysml-rtf@omg.org" Subject: Re: On issue 18653: View and Viewpoint Property Limitations X-Enigmail-Version: 1.5.1 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== I'll be pedantic again: an architect should not preclude possibilities simply because they lack the vision for how a concept might one day be used. One should limit the multiplicity of a property only if there is convincing reason why the number of associated concepts has to be bounded. Why must method:Behavior have only one or no behaviors? Would the capability fall apart if there were two or more? Lonnie VanZandt Chief Architect No Magic, Inc. Mailstop: 700 Central Expressway S, Suite 110, Allen, TX 75013 Office: 637 Witter Gulch Rd, Suite 425, Evergreen, CO 80439 Direct: 303-900-3048 Fax: 303-482-2943 Email: lvanzandt@nomagic.com Skype: lonnie.vanzandt On 5/7/2013 7:26 AM, BERNARD, Yves wrote: > Hi Eldad, > > I think that typing the method by Behavior is compatible with your implementation in Rhapsody since this behavior can be opaque. > > However, I support your point about the multiplicity of method: its upper bound shall be 1. > > Yves > > -----Original Message----- > From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] > Sent: mardi 7 mai 2013 15:01 > To: sysml-rtf@omg.org > Subject: On issue 18653: View and Viewpoint Property Limitations > > > Gentlemen, > > The change made to the method property of Viewpoint is confusing to me > since I don't think see how people would actually use that to generate a > View since it is not clear how to specify such methods and apply them on > the model (I mean is this like the getAllocationFrom() method specified in > OCL?) > > To me generating a View means selecting a subset of the model elements by > some criteria. > > In Rhapsody, to support such a thing we use something called Query which is > our tool specific way to select model elements without writing code. > Queries can have nested queries to support complex selection of elements. > > Since generating a View is really selecting model elements - I think that a > Query mechanism is more appropriate than just declaring that there is a > method of doing that. Especially since in most cases our Add-on code is > really external to the model and usually people don't model the add-ons > they apply on models. > > Another option is to say that this method is really an OCL query on the > model (or at least might be implemented as such) > > I realize it is very late but still we are in the discussion period and I > would like to raise this point for discussion. > > Eldad > > P.S. > Just a technicality, even if we stick with Behavior I think it should be > method:Behavior[0,1] and not method:Behavior[*] since I don't see any point > in having more than one behavior to select elements. > > > This mail has originated outside your organization, either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > > > > The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. > If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. > Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. > All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. > signature4.asc signature4.asc From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Tue, 7 May 2013 09:39:42 -0400 Subject: RE: On issue 18653: View and Viewpoint Property Limitations Thread-Topic: On issue 18653: View and Viewpoint Property Limitations Thread-Index: Ac5LKAIrqwhxU+ZxSsq1Zw729dK8jwAAEIvw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Lonnie, > Would the capability fall apart if there were two or more? The spec would need to say how the results of multiple queries affected the view, eg, are the results intersected or unioned? Conrad From: "BERNARD, Yves" To: "lvanzandt@nomagic.com" CC: Eldad Palachi , "sysml-rtf@omg.org" Date: Tue, 7 May 2013 15:54:27 +0200 Subject: RE: On issue 18653: View and Viewpoint Property Limitations Thread-Topic: On issue 18653: View and Viewpoint Property Limitations Thread-Index: Ac5LJ887OBg8yK5AS7qaHAoIXwKOVAAAT1nQ Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r47DsZDj024590 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Lonnie, As Conrad pointed out, I think we need to specify the semantics of our specification as much as possible. Consider that it is always easier to relax a constraint than to add it afterward (ascending compatibility). Yves -----Original Message----- From: Lonnie VanZandt [mailto:lvanzandt@nomagic.com] Sent: mardi 7 mai 2013 15:36 To: BERNARD, Yves Cc: Eldad Palachi; sysml-rtf@omg.org Subject: Re: On issue 18653: View and Viewpoint Property Limitations I'll be pedantic again: an architect should not preclude possibilities simply because they lack the vision for how a concept might one day be used. One should limit the multiplicity of a property only if there is convincing reason why the number of associated concepts has to be bounded. Why must method:Behavior have only one or no behaviors? Would the capability fall apart if there were two or more? Lonnie VanZandt Chief Architect No Magic, Inc. Mailstop: 700 Central Expressway S, Suite 110, Allen, TX 75013 Office: 637 Witter Gulch Rd, Suite 425, Evergreen, CO 80439 Direct: 303-900-3048 Fax: 303-482-2943 Email: lvanzandt@nomagic.com Skype: lonnie.vanzandt On 5/7/2013 7:26 AM, BERNARD, Yves wrote: > Hi Eldad, > > I think that typing the method by Behavior is compatible with your implementation in Rhapsody since this behavior can be opaque. > > However, I support your point about the multiplicity of method: its upper bound shall be 1. > > Yves > > -----Original Message----- > From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] > Sent: mardi 7 mai 2013 15:01 > To: sysml-rtf@omg.org > Subject: On issue 18653: View and Viewpoint Property Limitations > > > Gentlemen, > > The change made to the method property of Viewpoint is confusing to me > since I don't think see how people would actually use that to generate a > View since it is not clear how to specify such methods and apply them on > the model (I mean is this like the getAllocationFrom() method specified in > OCL?) > > To me generating a View means selecting a subset of the model elements by > some criteria. > > In Rhapsody, to support such a thing we use something called Query which is > our tool specific way to select model elements without writing code. > Queries can have nested queries to support complex selection of elements. > > Since generating a View is really selecting model elements - I think that a > Query mechanism is more appropriate than just declaring that there is a > method of doing that. Especially since in most cases our Add-on code is > really external to the model and usually people don't model the add-ons > they apply on models. > > Another option is to say that this method is really an OCL query on the > model (or at least might be implemented as such) > > I realize it is very late but still we are in the discussion period and I > would like to raise this point for discussion. > > Eldad > > P.S. > Just a technicality, even if we stick with Behavior I think it should be > method:Behavior[0,1] and not method:Behavior[*] since I don't see any point > in having more than one behavior to select elements. > > > This mail has originated outside your organization, either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > > > > The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. > If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. > Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. > All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. > This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From: "Delp, Christopher L (313K)" To: Eldad Palachi , "sysml-rtf@omg.org" Subject: RE: On issue 18653: View and Viewpoint Property Limitations Thread-Topic: On issue 18653: View and Viewpoint Property Limitations Thread-Index: AQHOSyMSdHUy/+0HdkiV5jyR4rxdnZj5u7tQ Date: Tue, 7 May 2013 13:57:03 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] X-Source-Sender: Christopher.L.Delp@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r47DvCcN024862 X-Brightmail-Tracker: AAAAAR16Wag= X-Brightmail-Tracker: AAAAAA== Hi Eldad, I think the goal here is to provide a hook for such mechanisms. In many of the practitioner developed "Document Generators" they all have some model element that ties the model to some kind of reusable reporting mechanism such as queries, analysis, style and presentation codes. Some of these use activity models to string together simple query mechanisms like collect, filter etc. Others bind them directly to a special docbook profile. The conclusion the AVGWG came to was that all of our implementations were consistent with SysML viewpoint and view. The limitation was that we could not apply our various reusable query and reporting mechanisms unless we converted method to an element in the model instead of a string. So the idea is that the viewpoint method provides a way to express these analysis (query, transformations, format presentation etc) to something that can be linked to multiple model views and reused. An example you might find interesting at JPL is how we have tied this mechanism to QVTo. We can use QVTo to write these Viewpoint methods in our document generator and so far it is compatible. -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Tuesday, May 07, 2013 6:01 AM To: sysml-rtf@omg.org Subject: On issue 18653: View and Viewpoint Property Limitations Gentlemen, The change made to the method property of Viewpoint is confusing to me since I don't think see how people would actually use that to generate a View since it is not clear how to specify such methods and apply them on the model (I mean is this like the getAllocationFrom() method specified in OCL?) To me generating a View means selecting a subset of the model elements by some criteria. In Rhapsody, to support such a thing we use something called Query which is our tool specific way to select model elements without writing code. Queries can have nested queries to support complex selection of elements. Since generating a View is really selecting model elements - I think that a Query mechanism is more appropriate than just declaring that there is a method of doing that. Especially since in most cases our Add-on code is really external to the model and usually people don't model the add-ons they apply on models. Another option is to say that this method is really an OCL query on the model (or at least might be implemented as such) I realize it is very late but still we are in the discussion period and I would like to raise this point for discussion. Eldad P.S. Just a technicality, even if we stick with Behavior I think it should be method:Behavior[0,1] and not method:Behavior[*] since I don't see any point in having more than one behavior to select elements. Subject: RE: On issue 18653: View and Viewpoint Property Limitations X-KeepSent: 19232C93:90CB1942-C2257B64:00530757; type=4; name=$KeepSent To: "Delp, Christopher L (313K)" Cc: "sysml-rtf@omg.org" X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Eldad Palachi Date: Tue, 7 May 2013 18:18:17 +0300 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.3FP2 ZX853FP2HF3|December 12, 2012) at 07/05/2013 18:18:07 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13050715-3548-0000-0000-00000551ADE9 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Hi Chris, Reading your reply I realize that in your approach generating a view does not mean selecting a subset of elements and putting it in a group or a view in the tool, it is a mechanism that can be used to generate documents that needs to accommodate format, model transformation (say into a table), etc. For example generating a matrix view listing all the connectors between the parts. I haven't thought about view generation this way since a View is a stereotype of a Package so I assumed it is just a grouping of references to model elements. Are you also proposing to change the View stereotype to something else than a package? In any case - I think this needs to be explicitly states in the spec (at least in the wording) Eldad From: "Delp, Christopher L (313K)" To: Eldad Palachi/Haifa/IBM@IBMIL, "sysml-rtf@omg.org" , Date: 07/05/2013 04:57 PM Subject: RE: On issue 18653: View and Viewpoint Property Limitations Hi Eldad, I think the goal here is to provide a hook for such mechanisms. In many of the practitioner developed "Document Generators" they all have some model element that ties the model to some kind of reusable reporting mechanism such as queries, analysis, style and presentation codes. Some of these use activity models to string together simple query mechanisms like collect, filter etc. Others bind them directly to a special docbook profile. The conclusion the AVGWG came to was that all of our implementations were consistent with SysML viewpoint and view. The limitation was that we could not apply our various reusable query and reporting mechanisms unless we converted method to an element in the model instead of a string. So the idea is that the viewpoint method provides a way to express these analysis (query, transformations, format presentation etc) to something that can be linked to multiple model views and reused. An example you might find interesting at JPL is how we have tied this mechanism to QVTo. We can use QVTo to write these Viewpoint methods in our document generator and so far it is compatible. -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Tuesday, May 07, 2013 6:01 AM To: sysml-rtf@omg.org Subject: On issue 18653: View and Viewpoint Property Limitations Gentlemen, The change made to the method property of Viewpoint is confusing to me since I don't think see how people would actually use that to generate a View since it is not clear how to specify such methods and apply them on the model (I mean is this like the getAllocationFrom() method specified in OCL?) To me generating a View means selecting a subset of the model elements by some criteria. In Rhapsody, to support such a thing we use something called Query which is our tool specific way to select model elements without writing code. Queries can have nested queries to support complex selection of elements. Since generating a View is really selecting model elements - I think that a Query mechanism is more appropriate than just declaring that there is a method of doing that. Especially since in most cases our Add-on code is really external to the model and usually people don't model the add-ons they apply on models. Another option is to say that this method is really an OCL query on the model (or at least might be implemented as such) I realize it is very late but still we are in the discussion period and I would like to raise this point for discussion. Eldad P.S. Just a technicality, even if we stick with Behavior I think it should be method:Behavior[0,1] and not method:Behavior[*] since I don't see any point in having more than one behavior to select elements. From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Thu, 9 May 2013 09:35:08 -0400 Subject: RE: Markups to Issue 18653 in Ballot 5 2013-05-06 based on Feedback from RTF Thread-Topic: Markups to Issue 18653 in Ballot 5 2013-05-06 based on Feedback from RTF Thread-Index: Ac5HBqrSbEww5ECi/ECo1dtuB29MTAAARP/AAAZ0dpAAJ9qE0AABU6kgAAlSO/AAAIiuAAAAL1ZAAAIObeAAAJWh0AAANaOAAAGKDqAAAKPrYAALx8yAACgHoTAABr7gUAAIaMegAKVND7AAMvwWMAASaNSw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Sandy, et al, (we're in RTF review so I'm sending this to the list) > Also, please do a final review to see if any other changes are > required for Ballot 5. About the constraints on viewpoint, see below. Conrad [1] A viewpoint cannot be the classifier of an instance specification. If viewpoints can't have instances, why are they classes? [3] The property owned Attribute must be empty. Seems like modelers might want to extend viewpoints with their own properties. [2] The model is a required argument for the method. Constraints need to be specified in terms of the abstract syntax, which doesn't currently have "the model". DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=XEMfFkoBh9+9qh6r/e0XsPqM6JMwXrqWKkY4q0RovYY=; b=XQkS+M78O75Rzje7yxPUDEPdki67oPDM3WHnr5FzpFlg1f/mrd0z2jlGcVJdJHa4kG kj8697HCEp2uVzsUK0MxFPW+YDR6fu5y4RTM9/cXAECjG4Ij0l0jXttvBiSmfSfqRJEt E2xWkXW2c2330WAxk1AwXQbvW0GK5tfhCcy5AXX5WNH9lnBsVXhPE5LXDfUHxUKDVAs8 FZ3tqjG8e5Z/jhqoAA8/LouUFkB4EVKq2ngpd9v3c1HSTyuVe4in7kP78yMSToNviE0h bQTX2PtnQCoM7PxddwmntyG/RuUOx9mJ5RiAk1qj9TfqW7e3Sj4Y/ExGF8dhybA8TAv3 CT3Q== X-Received: by 10.50.61.232 with SMTP id t8mr2478180igr.37.1368108380794; Thu, 09 May 2013 07:06:20 -0700 (PDT) From: "Sanford Friedenthal" To: "'Bock, Conrad'" Cc: Subject: RE: Markups to Issue 18653 in Ballot 5 2013-05-06 based on Feedback from RTF Date: Thu, 9 May 2013 10:06:13 -0400 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5HBqrSbEww5ECi/ECo1dtuB29MTAAARP/AAAZ0dpAAJ9qE0AABU6kgAAlSO/AAAIiuAAAAL1ZAAAIObeAAAJWh0AAANaOAAAGKDqAAAKPrYAALx8yAACgHoTAABr7gUAAIaMegAKVND7AAMvwWMAASaNSwAADxzMA= X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAQzCY6M= X-Brightmail-Tracker: AAAAAA== Conrad Constraints 1,3 are in SysML v1.3 as well as previous versions. There are no issues filed against these constraints, but we can revisit this in the next ballots. It is late in the game to try and address this for ballot 5 which is due tomorrow. We did add constraint 2. Do you have a proposed update to include to incorporate model into the abstract syntax. If not, we can either delete the constraint or add the additional abstract syntax in the next ballot. Please make a recommendation. In addition to any changes above, the proposed updates to the final ballot 5 version of Issue 18653 include - Deleting the 's' on stakeholders - Changing multiplicity on method to 0..1 - Extending Stakeholder by Classifier instead of Class This is based on feedback to date. Regards, Sandy -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Thursday, May 09, 2013 9:35 AM To: sysml-rtf@omg.org Subject: RE: Markups to Issue 18653 in Ballot 5 2013-05-06 based on Feedback from RTF Sandy, et al, (we're in RTF review so I'm sending this to the list) > Also, please do a final review to see if any other changes are > required for Ballot 5. About the constraints on viewpoint, see below. Conrad [1] A viewpoint cannot be the classifier of an instance specification. If viewpoints can't have instances, why are they classes? [3] The property owned Attribute must be empty. Seems like modelers might want to extend viewpoints with their own properties. [2] The model is a required argument for the method. Constraints need to be specified in terms of the abstract syntax, which doesn't currently have "the model". From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Thu, 9 May 2013 10:22:07 -0400 Subject: RE: Markups to Issue 18653 in Ballot 5 2013-05-06 based on Feedback from RTF Thread-Topic: Markups to Issue 18653 in Ballot 5 2013-05-06 based on Feedback from RTF Thread-Index: Ac5HBqrSbEww5ECi/ECo1dtuB29MTAAARP/AAAZ0dpAAJ9qE0AABU6kgAAlSO/AAAIiuAAAAL1ZAAAIObeAAAJWh0AAANaOAAAGKDqAAAKPrYAALx8yAACgHoTAABr7gUAAIaMegAKVND7AAMvwWMAASaNSwAADxzMAAAHLIQA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Sandy, > Constraints 1,3 are in SysML v1.3 as well as previous versions. Thanks, but if you're restating what's in 1.3, this constraint from 1.3 seems to be missing: [2] The property ownedOperation must be empty. Was that intentional? Chris is saying on the telecon just now that it wasn't, so if you and others agree, you can put it back. > We did add constraint 2. Do you have a proposed update to include to > incorporate model into the abstract syntax. If not, we can either delete the > constraint or add the additional abstract syntax in the next ballot. Please > make a recommendation. It would probably better to remove the constraint, and discuss updating the abstract syntax and adding a constraint in ballot 6. Conrad DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=35AjiPQUpWrfbqPw9IFvMemnTQs2KvG7rV7wDdOARK4=; b=w9GFa0oBaoYgcwcWRwaDawiSuaaTs/7M6RURUz1Himzv3GTH0hPpP0r0MfOysMlQDO nxhg5J4d4TJ+a6dO2NtQf2DNdh7O3cqipF6QojXUkcY/ZUQh7o6OuPk1D2U3ROug6eu+ yt9v+WwLwRffT5i0gwz4E7huHoXXsi4KLwsQsGiAfl2WNQnvNqyGQ9GMOHO7PdA9jTje k8w7IqkwoKnekFi3+YtZ63RKfx3xWReyoUZ/uLKDgO5hCE1S9PgdKw56hO1i2ksXjCja KtvdSXnVFF7mUK0TEgTC+7L1dpr05oNAfgoTFgiO2+NIQDsMkhI/xIGyt3603+qVhJrK oiWg== X-Received: by 10.60.178.139 with SMTP id cy11mr4339310oec.120.1368109545374; Thu, 09 May 2013 07:25:45 -0700 (PDT) From: "Sanford Friedenthal" To: "'Bock, Conrad'" Cc: Subject: RE: Markups to Issue 18653 in Ballot 5 2013-05-06 based on Feedback from RTF Date: Thu, 9 May 2013 10:25:37 -0400 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5HBqrSbEww5ECi/ECo1dtuB29MTAAARP/AAAZ0dpAAJ9qE0AABU6kgAAlSO/AAAIiuAAAAL1ZAAAIObeAAAJWh0AAANaOAAAGKDqAAAKPrYAALx8yAACgHoTAABr7gUAAIaMegAKVND7AAMvwWMAASaNSwAADxzMAAAHLIQAAAjO0g X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAQzCY6M= X-Brightmail-Tracker: AAAAAA== Conrad I will add in the original constraint 2 and delete the new constraint 2 in the updated resolution. Sandy -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Thursday, May 09, 2013 10:22 AM To: sysml-rtf@omg.org Subject: RE: Markups to Issue 18653 in Ballot 5 2013-05-06 based on Feedback from RTF Sandy, > Constraints 1,3 are in SysML v1.3 as well as previous versions. Thanks, but if you're restating what's in 1.3, this constraint from 1.3 seems to be missing: [2] The property ownedOperation must be empty. Was that intentional? Chris is saying on the telecon just now that it wasn't, so if you and others agree, you can put it back. > We did add constraint 2. Do you have a proposed update to include to > incorporate model into the abstract syntax. If not, we can either delete the > constraint or add the additional abstract syntax in the next ballot. Please > make a recommendation. It would probably better to remove the constraint, and discuss updating the abstract syntax and adding a constraint in ballot 6. Conrad From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Fri, 10 May 2013 10:06:29 -0400 Subject: RE: Resolution for Issue 18653 on View and Viewpoint Property Limitations for ballot 5 dated May 10, 2013 Thread-Topic: Resolution for Issue 18653 on View and Viewpoint Property Limitations for ballot 5 dated May 10, 2013 Thread-Index: AQHOSmQVdIpmdf2qxk653BygTNdTkZj+c20AgAAFezA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR15Qr0= X-Brightmail-Tracker: AAAAAA== Sandy, Thanks for these updates. Couple more comments. This can be removed: In Section 7.3.1 (Diagram Extensions), insert the following new subsection: 7.3.1.1 View and Viewpoint The "viewpoint" can display its stereotype properties using standard stereotype notation. since it doesn't actual extended any UML notation. The Diagram Extensions section is only for changes or additions to UML notation, which I gather is not the case here. Also, the Constraints section in Stakeholder isn't needed because there aren't any. Other stereotypes that don't have constraints also don't have a constraints section heading. Conrad Subject: View and Viewpoints (resolution for issue 18653) X-KeepSent: D1F9D54D:A1ECCE08-C2257B6D:0031B596; type=4; name=$KeepSent To: Christopher.L.Delp@jpl.nasa.gov Cc: sysml-rtf@omg.org X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Eldad Palachi Date: Thu, 16 May 2013 12:05:53 +0300 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.3FP2 ZX853FP2HF3|December 12, 2012) at 16/05/2013 12:05:43 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13051608-1948-0000-0000-00000529CD28 X-Virus-Scanned: amavisd-new at omg.org Hi Chris, I am still confused about the resolution submitted for ballot 5. My current understanding of a View is that it is a kind of package that references a subset of a model, while a Viewpoint is a set of rules to choose the relevant elements to be included in the View. To me this is separate from the document generation rules that should include formatting, ordering, producing a table of content, index, etc. If a View should be changed to something that represents a document then let's define it as such and not as a kind of a package. We could introduce a new stereotype called <> extending UML artifact that contains the additional data. A Document may relate to a <> or perhaps inherit from it (assuming it's legal profiling wise). This model elements would be specific to document and may be characterized by things such as URL, format (pdf, html, etc.), and more. In addition we need to define a set of relationships to define the structure of the document and the formatting instructions of the various elements. Perhaps these extensions should first be specified in a non-normative annex. As it stands now - I don't see any point in implementing the current proposal for this issue since I don't know how to explain the benefit for the users. It doesn't really offer a solution to produce documents by modeling them as I understand the real motivation is - I understand it is a sort of a "first step" but that in itself has little value from my point of view. I propose deferring this issue until a more complete solution is proposed that explicitly addresses document generation. Eldad From: GERARD Sebastien 166342 To: Eldad Palachi , "Christopher.L.Delp@jpl.nasa.gov" CC: "sysml-rtf@omg.org" Subject: RE: View and Viewpoints (resolution for issue 18653) Thread-Topic: View and Viewpoints (resolution for issue 18653) Thread-Index: AQHOUhSmnjR7/C2BxE+g+zTfac2lM5kHhwtQ Date: Thu, 16 May 2013 09:16:09 +0000 Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.105] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19820.002 x-tm-as-result: No--49.231000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r4G9GN4D017019 Hi, For me, a view is a visual representation (mainly dedicated to human) of a model or part of a model. A viewpoint is a definition of what the view itself (what is to show, how to build the view, and so on). A document is then a kind of view. Why not having <> inheriting from <>? Cheers... SĂ© ------------------------------------------------------------------------------------------------------------------------------------------------ SĂ©stien GĂ©rd +33 (0)1 69 08 58 24 / +33(0)6 88 20 00 47 CEA Saclay Nano-INNOV Institut CARNOT CEA LIST DILS/Laboratoire d'IngĂ©erie dirigĂ©par les modès pour les Systès EmbarquĂ©(LISE), Point Courrier n°174 91 191 Gif sur Yvette CEDEX www.eclipse.org/papyrus > -----Message d'origine----- > De : Eldad Palachi [mailto:eldad.palachi@il.ibm.com] > EnvoyĂ© jeudi 16 mai 2013 11:06 > Ă€: Christopher.L.Delp@jpl.nasa.gov > Cc : sysml-rtf@omg.org > Objet : View and Viewpoints (resolution for issue 18653) > > > Hi Chris, > > I am still confused about the resolution submitted for ballot 5. > > My current understanding of a View is that it is a kind of package that > references a subset of a model, while a Viewpoint is a set of rules to choose the > relevant elements to be included in the View. > > To me this is separate from the document generation rules that should include > formatting, ordering, producing a table of content, index, etc. > > If a View should be changed to something that represents a document then let's > define it as such and not as a kind of a package. > > We could introduce a new stereotype called <> extending UML > artifact that contains the additional data. A Document may relate to a > <> or perhaps inherit from it (assuming it's legal profiling wise). > > This model elements would be specific to document and may be characterized > by things such as URL, format (pdf, html, etc.), and more. In addition we need > to define a set of relationships to define the structure of the document and the > formatting instructions of the various elements. Perhaps these extensions > should first be specified in a non-normative annex. > > As it stands now - I don't see any point in implementing the current proposal for > this issue since I don't know how to explain the benefit for the users. > > It doesn't really offer a solution to produce documents by modeling them as I > understand the real motivation is - I understand it is a sort of a "first step" but > that in itself has little value from my point of view. > > I propose deferring this issue until a more complete solution is proposed that > explicitly addresses document generation. > > Eldad Subject: RE: View and Viewpoints (resolution for issue 18653) X-KeepSent: CC3B73EE:4C2A153C-C2257B6D:003332EF; type=4; name=$KeepSent To: GERARD Sebastien 166342 Cc: "Christopher.L.Delp@jpl.nasa.gov" , "sysml-rtf@omg.org" X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Eldad Palachi Date: Thu, 16 May 2013 12:32:25 +0300 X-MIMETrack: Serialize by Router on D06ML319/06/M/IBM(Release 8.5.3FP2 ZX853FP2HF3|December 12, 2012) at 16/05/2013 12:32:14 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13051609-0342-0000-0000-0000050BB8A2 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r4G9WXic017721 Hi Seb, I have no objections of having Document inheriting from View - I was just not 100% sure it is legal to have a stereotype extending one meta-class inherit a stereotype extending a different meta-class. Not sure what you mean by "visual representation" - since there were no special notations for View as far as I know that actually display the relevant elements in a diagram/table/tree/other. All I am really saying is that the current proposal seems incomplete and a more complete proposal should be made, at least so I can explain to my users how to use the new properties added to the stereotypes of View and Viewpoint. Eldad From: GERARD Sebastien 166342 To: Eldad Palachi/Haifa/IBM@IBMIL, "Christopher.L.Delp@jpl.nasa.gov" , Cc: "sysml-rtf@omg.org" Date: 16/05/2013 12:16 PM Subject: RE: View and Viewpoints (resolution for issue 18653) Hi, For me, a view is a visual representation (mainly dedicated to human) of a model or part of a model. A viewpoint is a definition of what the view itself (what is to show, how to build the view, and so on). A document is then a kind of view. Why not having <> inheriting from <>? Cheers... SĂ© ------------------------------------------------------------------------------------------------------------------------------------------------ SĂ©stien GĂ©rd +33 (0)1 69 08 58 24 / +33(0)6 88 20 00 47 CEA Saclay Nano-INNOV Institut CARNOT CEA LIST DILS/Laboratoire d'IngĂ©erie dirigĂ©par les modès pour les Systès EmbarquĂ©(LISE), Point Courrier n°174 91 191 Gif sur Yvette CEDEX www.eclipse.org/papyrus > -----Message d'origine----- > De : Eldad Palachi [mailto:eldad.palachi@il.ibm.com] > EnvoyĂ© jeudi 16 mai 2013 11:06 > Ă€: Christopher.L.Delp@jpl.nasa.gov > Cc : sysml-rtf@omg.org > Objet : View and Viewpoints (resolution for issue 18653) > > > Hi Chris, > > I am still confused about the resolution submitted for ballot 5. > > My current understanding of a View is that it is a kind of package that > references a subset of a model, while a Viewpoint is a set of rules to choose the > relevant elements to be included in the View. > > To me this is separate from the document generation rules that should include > formatting, ordering, producing a table of content, index, etc. > > If a View should be changed to something that represents a document then let's > define it as such and not as a kind of a package. > > We could introduce a new stereotype called <> extending UML > artifact that contains the additional data. A Document may relate to a > <> or perhaps inherit from it (assuming it's legal profiling wise). > > This model elements would be specific to document and may be characterized > by things such as URL, format (pdf, html, etc.), and more. In addition we need > to define a set of relationships to define the structure of the document and the > formatting instructions of the various elements. Perhaps these extensions > should first be specified in a non-normative annex. > > As it stands now - I don't see any point in implementing the current proposal for > this issue since I don't know how to explain the benefit for the users. > > It doesn't really offer a solution to produce documents by modeling them as I > understand the real motivation is - I understand it is a sort of a "first step" but > that in itself has little value from my point of view. > > I propose deferring this issue until a more complete solution is proposed that > explicitly addresses document generation. > > Eldad From: "Delp, Christopher L (313K)" To: Eldad Palachi , GERARD Sebastien 166342 CC: "sysml-rtf@omg.org" Subject: RE: View and Viewpoints (resolution for issue 18653) Thread-Topic: View and Viewpoints (resolution for issue 18653) Thread-Index: AQHOUhSVZedhhCy4r0KpnW7EbH0h4ZkH/TCAgAAEi4D//8nYkA== Date: Thu, 16 May 2013 13:23:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.27] X-Source-Sender: Christopher.L.Delp@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r4GDNjWU027455 X-Brightmail-Tracker: AAAAAh15Qr0delmo X-Brightmail-Tracker: AAAAAA== Hi Eldad, The issue is that the view can take the form of multiple artifacts. Documents, animations form simulations etc. We need something that symbolizes what we really care about- the view. The is just a representation of the result. SysML is not capable representing all these products concretely. <> would be far too restrictive for someone who wants to generate a slide deck and a website for example. The viewpoint remains the place where the rules for constructing the view and producing the artifact reside. -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Thursday, May 16, 2013 2:32 AM To: GERARD Sebastien 166342 Cc: Delp, Christopher L (313K); sysml-rtf@omg.org Subject: RE: View and Viewpoints (resolution for issue 18653) Hi Seb, I have no objections of having Document inheriting from View - I was just not 100% sure it is legal to have a stereotype extending one meta-class inherit a stereotype extending a different meta-class. Not sure what you mean by "visual representation" - since there were no special notations for View as far as I know that actually display the relevant elements in a diagram/table/tree/other. All I am really saying is that the current proposal seems incomplete and a more complete proposal should be made, at least so I can explain to my users how to use the new properties added to the stereotypes of View and Viewpoint. Eldad From: GERARD Sebastien 166342 To: Eldad Palachi/Haifa/IBM@IBMIL, "Christopher.L.Delp@jpl.nasa.gov" , Cc: "sysml-rtf@omg.org" Date: 16/05/2013 12:16 PM Subject: RE: View and Viewpoints (resolution for issue 18653) Hi, For me, a view is a visual representation (mainly dedicated to human) of a model or part of a model. A viewpoint is a definition of what the view itself (what is to show, how to build the view, and so on). A document is then a kind of view. Why not having <> inheriting from <>? Cheers... SĂ© ------------------------------------------------------------------------------------------------------------------------------------------------ SĂ©stien GĂ©rd +33 (0)1 69 08 58 24 / +33(0)6 88 20 00 47 CEA Saclay Nano-INNOV Institut CARNOT CEA LIST DILS/Laboratoire d'IngĂ©erie dirigĂ©par les modès pour les Systès EmbarquĂ©(LISE), Point Courrier n°174 91 191 Gif sur Yvette CEDEX www.eclipse.org/papyrus > -----Message d'origine----- > De : Eldad Palachi [mailto:eldad.palachi@il.ibm.com] EnvoyĂ© jeudi 16 > mai 2013 11:06 Ă€: Christopher.L.Delp@jpl.nasa.gov Cc : > sysml-rtf@omg.org Objet : View and Viewpoints (resolution for issue > 18653) > > > Hi Chris, > > I am still confused about the resolution submitted for ballot 5. > > My current understanding of a View is that it is a kind of package > that references a subset of a model, while a Viewpoint is a set of > rules to choose the > relevant elements to be included in the View. > > To me this is separate from the document generation rules that should include > formatting, ordering, producing a table of content, index, etc. > > If a View should be changed to something that represents a document > then let's > define it as such and not as a kind of a package. > > We could introduce a new stereotype called <> extending UML > artifact that contains the additional data. A Document may relate to a > <> or perhaps inherit from it (assuming it's legal profiling wise). > > This model elements would be specific to document and may be characterized > by things such as URL, format (pdf, html, etc.), and more. In addition > we need > to define a set of relationships to define the structure of the > document and the > formatting instructions of the various elements. Perhaps these > extensions should first be specified in a non-normative annex. > > As it stands now - I don't see any point in implementing the current proposal for > this issue since I don't know how to explain the benefit for the users. > > It doesn't really offer a solution to produce documents by modeling > them as I > understand the real motivation is - I understand it is a sort of a > "first step" but > that in itself has little value from my point of view. > > I propose deferring this issue until a more complete solution is > proposed that > explicitly addresses document generation. > > Eldad From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Fri, 10 May 2013 15:06:08 -0400 Subject: RE: Resolution for Issue 18653 on View and Viewpoint Property Limitations for ballot 5 dated May 10, 2013, update Thread-Topic: Resolution for Issue 18653 on View and Viewpoint Property Limitations for ballot 5 dated May 10, 2013, update Thread-Index: Ac5NsOBc8H4uvlvSSn+1KWFMnuDAeA== Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Roger, I didn't see any response to this, so I took the liberty of making the edits. They just remove sections we don't normally include (diagram extensions and constraints when there aren't any, see change marks). There are no visio changes. Conrad -----Original Message----- From: Bock, Conrad Sent: Friday, May 10, 2013 10:06 AM To: sysml-rtf@omg.org Subject: RE: Resolution for Issue 18653 on View and Viewpoint Property Limitations for ballot 5 dated May 10, 2013 Sandy, Thanks for these updates. Couple more comments. This can be removed: In Section 7.3.1 (Diagram Extensions), insert the following new subsection: 7.3.1.1 View and Viewpoint The "viewpoint" can display its stereotype properties using standard stereotype notation. since it doesn't actual extended any UML notation. The Diagram Extensions section is only for changes or additions to UML notation, which I gather is not the case here. Also, the Constraints section in Stakeholder isn't needed because there aren't any. Other stereotypes that don't have constraints also don't have a constraints section heading. Conrad From: "Delp, Christopher L (313K)" To: Eldad Palachi CC: Burkhart Roger M , "Bock, Conrad" , "Rouquette, Nicolas F (313K)" , "sysml-rtf@omg.org" , "'Yves BERNARD' (Yves.Bernard@airbus.com)" Subject: RE: update of draft ballot 5 available for discussion through Friday, May 10, 2013 Thread-Topic: update of draft ballot 5 available for discussion through Friday, May 10, 2013 Thread-Index: Ac5FD/XWL6VnrFFtRUSfls9Q+jRitwFjsuKA//+wQoD//Pg18IAGyIgA//Qj8lA= Date: Thu, 16 May 2013 15:48:30 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.27] X-Source-Sender: Christopher.L.Delp@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r4GFmpUJ017215 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit Hi Eldad, There are a couple subtleties to what you propose. In SysML we have no way to separate the method definition from the invocation context of the method. To over-come this we use a "view" modeling element to provide this context. The view modeling element is related to the model elements that will be exposed when the artifact is generated. Yves and I discussed an example that I will attempt to describe: If you were to look at this problem in pseudo-code you would have perhaps something like this: For a class: view(modelElementArguments[])) Some function definition that represents the method: Artifact someViewpointMethod(view) Now I call this function: MyNewArtifac1 = someViewpointMethod (MyView1(MyModelElements1)) MyNewArtifact2 = someViewpointMethod (MyView2(MyModelElements2)) MyNewArtifact3 = someViewpointMethod (MyView3(MyModelElements3)) When I call the function in code, I get an instance of the definition that allows me to separately relate the view to the corresponding model whose elements will be exposed in the view. If we do this is SysML the viewpoint and the method map to the function definition. They cannot have view specific or model-specific information related to them. The consequence of this in SysML means that the viewpoint and method cannot have relationships attached to them only for the model. -----Original Message----- From: Eldad Palachi [mailto:eldad.palachi@il.ibm.com] Sent: Wednesday, May 08, 2013 11:48 AM To: Delp, Christopher L (313K) Cc: Burkhart Roger M; Bock, Conrad; Rouquette, Nicolas F (313K); sysml-rtf@omg.org Subject: RE: update of draft ballot 5 available for discussion through Friday, May 10, 2013 Hi Chris, You write: "The viewpoint generates an artifact (document, document section, slide etc) that is a rendering of the View of the model. The View modeling element is a model representation for that artifact. The model that is expressed by the View currently related by the import relationship. This way the viewpoint has a distinct usage that allows the method to distinguish between the different Views and Viewpoints that use it." Please clarify "model representation for that artifact" Do you mean that a View is a model (package) that a tool can transform to a document in one click? If that is the case, why do we need to have it in the model and not directly generate the document? In my opinion it makes more sense to first use the Viewpoint to create the View (package) with the references to the relevant model elements, then work on the View as a model of the document specifying the right order, formatting, sections, etc. and only then run a generator and produce the actual artifact. I think that for generating such a View a query mechanism is enough. As it is now, I don't understand how this should work and I think this issue needs more discussion. Eldad From: "Delp, Christopher L (313K)" To: "Rouquette, Nicolas F (313K)" , "Burkhart Roger M" , "sysml-rtf@omg.org" , Cc: "Bock, Conrad" Date: 08/05/2013 06:00 PM Subject: RE: update of draft ballot 5 available for discussion through Friday, May 10, 2013 Hi Nick, I have responded to your questions below but on some of them I need some clarification. From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Monday, May 06, 2013 9:30 AM To: Burkhart Roger M; sysml-rtf@omg.org Cc: Bock, Conrad Subject: Re: update of draft ballot 5 available for discussion through Friday, May 10, 2013 15075: See Michael's comments 18653: this resolution needs work. It seems that the reuse argument made for Stakeholder could be equally made for Concern and Purpose. Why does Stakeholder deserve reification as a Class? Why leave Concern and Purpose as strings which makes their reuse practically difficult? I agree. This will be handled in a future ballot. We still need consensus on how to make concern reusable. Purpose has not been proposed for being reusable since it is a specific property of a viewpoint. About: Viewpoint::method : Behavior[*] Since this is a stereotype property, it cannot have composite aggregation. This means that a given Behavior could be a method of several Viewpoints. When a Behavior executes to generate a View for a particular Viewpoint, how does this Behavior access the Viewpoint when this Behavior could be a method of several Viewpoints? The viewpoint generates an artifact (document, document section, slide etc) that is a rendering of the View of the model. The View modeling element is a model representation for that artifact. The model that is expressed by the View currently related by the import relationship. This way the viewpoint has a distinct usage that allows the method to distinguish between the different Views and Viewpoints that use it. Why is a Viewpoint restricted not to have any attributes or operations? Why is this restriction necessary? These constraints were already in the spec. we have not revisited them. I can add this to the agenda if it is useful. Stakeholder description: A stakeholder is a model element that represents a role, group or individual who has concerns that will be addressed by the View of the Model. Since a View is generated from a Viewpoint, a well-formed model could have Viewpoints and Stakeholders but no Views yet . I.e., they haven't been generated yet. What does it mean then for a Stakeholder to have concerns about non-existent Views? A well formed model would have views and viewpoints described in the model. IT would not have any artifacts generated form the model yet. Isn't it that a Stakeholder has concerns about Viewpoints on a model and that these concerns apply to the Views generated from these Viewpoints? The Viewpoint-View concept is based on a 2-way communication model. The viewpoint frames the concerns of the stakeholders against the rules fopr creating a conformant view. In other words the viewpoint tells the stakeholder .heres what I heard you say you expect to see in a conformant view. The view represents the artifact that will respond to that will respond to the viewpoint. this allows the communication to be analyzed to see if the architect and stakeholder are communicating on the expectation separately from the technical content of the view. 17253: See issues 18438, 18439, and 18441 for resolution I only found 18438 (and 18440) in ballot 4 I have not found 18439 nor 18441 anywhere in ballots 1 through 5 Are 18439 and 18441 missing from ballot 5? - Nicolas. From: Burkhart Roger M Date: Monday, May 6, 2013 7:14 AM To: "sysml-rtf@omg.org" Cc: Conrad Bock Subject: update of draft ballot 5 available for discussion through Friday, May 10, 2013 An update of the draft Ballot 5, reflecting discussions since it was first posted a week ago, is available for review and discussion on the SysML 1.4 RTF wiki at http://www.omg.org/members/sysml-rtf-wiki. (Click on the Ballot 5 link.) The current review period will continue through this Friday, May 10, 2013. Updates were made to resolutions 18653 in the Model Elements clause, 15075, 18435, and 18681 in the Blocks clause, and 18561 in the Requirements clause. --Roger From: Burkhart Roger M [mailto:BurkhartRogerM@JohnDeere.com] Sent: Monday, April 29, 2013 2:30 PM To: sysml-rtf@omg.org Cc: Bock, Conrad Subject: draft ballot 5 available for discussion through Friday, May 10, 2013 A draft Ballot 5 is available for review and discussion on the SysML 1.4 RTF wiki at http://www.omg.org/members/sysml-rtf-wiki. (Click on the Ballot 5 link.) Ballot 5 will be open for discussion through Friday, May 10, 2013. The normal two-week voting period will then begin by Monday, May 13. Following are ballot review instructions which appear at the bottom of the ballot page: The review period is currently open. Please download the PDF file above to review the detail of the proposed resolutions, which will be frozen at the start of voting. If you have any concerns or questions about any of the proposed resolutions, please send a message to the sysml-rtf@omg.org mailing list. Review and discussion of this ballot will occur on regularly scheduled RTF telecons during the review period before voting begins. 18653_resolved-130510.doc 18653_resolved-130510.doc