Issue 18719: View and Viewpoint Construction Limitations (from Issue 18391 c), d), e) and g)) (sysml-rtf) Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: 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 description limitations. The current viewpoint description should be clarified to note that it should specify the presentation of the information as well as the information itself. This may require additional viewpoint properties to enable the specification of the form and format of the information. The form of the data in this context refers to how the information is presented such as data values that are in tabular form or a plot. The format of the data in this context refers to the file format that is used for the rendering application. b) View import limitations. The current View description says “Views are allowed to import other elements including other packages and other Views that conform to the Viewpoint”. View also includes a constraint that ‘A view can only own element import, package import, comment and constraint elements’. This concept of importing model elements into a package is not a sufficient means for constructing Views. The relationship between the view and the model elements should reflect the concept that the View can be constructed by defining operations to query models and other sources of data, and perform other operations on the information to present it in a form that is useful to the stakeholders. c) Other view construction limitations. A View conforming to a Viewpoint may be constructed from different sets of information that may be rendered as an entire document, a part of a document, a set of powerpoint slides or an individual slide, a video or series of videos, or other form. A typical example may be a security View that represents security requirements, design, and verification information. This requires the View to be constructed from sub-views, and that these sub-views must be ordered in a particular way to present to the user. An example would be the ordering of sections in a document, where each section represents a subview which in-turn represents selected information. A current limitation is the inability to express the ordering and general organization of the View and corresponding subviews that comprise the View (Note: this is a structural ordering and not a temporal ordering). Some of the current approaches have addressed this limitation by including a dependency relationship between the subviews. The relationships can express a precedence relationship (i.e.., next) and a decomposition relationship (i.e., first). A simple example of how these relationships are used to construct a View that is presented to the stakeholder as a document is included below. In the above example, different subviews correspond to the different sections of the document that comprise the View. For example, some text with a table of information from one part of the model may appear in Section 1, and some other text with a diagram that represents other model information may appear in Section 2. Each section of the document may require different viewpoints to specify the query and presentation. There is currently no way to describe that a View that conforms to a Viewpoint contains multiple subviews with the relationships as indicated in the figure. There is a need to create a View that contains subviews that are related to one another with the types of relationships indicated (e.g., first, next). (Note: It is anticipated that the View and subviews should be reusable, and may require additional metadata). In the example above, each section of the document corresponds to a particular subview. However, we do not want to restrict a subview so that the information cannot be distributed across multiple sections of a document, or across multiple documents. d) Reuse of view and viewpoint. There needs to be sufficient expression to construct reusable definitions of view and viewpoint. These mechanisms may include composition, specialization, model libraries, and others. e) Other View and Viewpoint Mechanisms. There may be additional ways to create views more directly in the model. For example, a view may correspond to a filtered subset of a set of parts on an ibd corresponding that are based on some criteria (e.g., all electrical parts). This is similar to issue 13928 called the partition construct (later referred to as element group). Resolution: Revised Text: Actions taken: May 15, 2013: received issue Discussion: End of Annotations:===== m: Phil Astle To: "sysml-rtf@omg.org" Subject: RE: draft ballot 6 available for review and discussion through Thursday, June 6, 2013 Thread-Topic: draft ballot 6 available for review and discussion through Thursday, June 6, 2013 Thread-Index: Ac5YaSdDeZ/ben5zTAmtJOgGQ3mdXwDUq0bg Date: Tue, 28 May 2013 16:54:56 +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: B9C0C5236DF93032E28694 X-Virus-Scanned: amavisd-new at omg.org A few questions on the resolution for 18719: 1. There.s no mention of moving the current View to the deprecated section and adding a new Stereotype (possibly with a new name). Has this been missed or has there been a decision made to not do this? 2. The multiplicities for the Properties of Viewpoint don.t seem to match the text . plus they don.t make sense to me: a. language and presentation are 0..* but method is 0..1. If you have multiple languages and presentations to handle, wouldn.t you need multiple methods? It seems to be what the text implies when it states .[2] The view is constructed in accordance with the methods and languages that are specified as part of the viewpoint. SysML does not define the specific methods.. Should method be 0..*, language and presentation 0..1 or is it correct that they.re different? b. Further to [2a], if you.re allowed more than one language and presentation, should they be defined as {ordered} so you can pair up the language with the presentation? c. purpose is shown with no multiplicity which (I believe) means 1..1. Is this deliberate or should it be 0..1 to match the others? 3. The constraint for the presentation topic seems overly restrictive. Some presentation formats that users might want to define may not have a URI defined. Would it be better to move this text out of the constraints section and mention it as a suggested, best practise in the attribute description? 4. In one of the RTF calls, I.m sure inheritance and Views were mentioned. Should there be something in the resolution that addresses this? 5. The description for /viewReference states .The ordered list of «view» elements referenced by a view via shared association., yet constraint [2] states .The subordinate view attribute is restricted to listing Property elements or association roles typed by «view».. Is constraint [2] talking about a different property? If not, are these statements contradictory? Also, should there be something in the constraints section that states that all Properties typed by a View should be Shared? 6. Further to [5], does /viewReference only list the Properties typed by Views that are directly owned by the current View, or does it go through the part hierarchy and list all of them recursively? 7. Are Views limited to only having Properties typed by other Views? If not, what do the other Properties mean? 8. Are there any other constraints on Views missing. For example: a. Can you instantiate them? b. Can they own nested classifiers such as Blocks/Requirements? c. Can they be used as a type for Properties owned by non-Views? Phil From: Burkhart Roger M [mailto:BurkhartRogerM@johndeere.com] Sent: 24 May 2013 11:27 To: sysml-rtf@omg.org Subject: draft ballot 6 available for review and discussion through Thursday, June 6, 2013 A draft Ballot 6 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 6 link.) Ballot 6 will be open for discussion through Thursday, June 6, 2013. A somewhat-shortened voting period will begin after the review period has closed. 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 8383 (20130528) __________ The message was checked by ESET Endpoint Antivirus. http://www.eset.com __________ Information from ESET Endpoint Antivirus, version of virus signature database 8385 (20130528) __________ The message was checked by ESET Endpoint Antivirus. http://www.eset.com From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Wed, 29 May 2013 14:57:55 -0400 Subject: RE: draft ballot 6 available for review, 18719 Thread-Topic: draft ballot 6 available for review, 18719 Thread-Index: Ac5cnmMbaSqFwBIJTL6NibZ4T/V3ug== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org Chris, et al, Some comments on 18719 below. Conrad - Not sure why views can only be related by reference. Maybe some views are only used or make sense in the context of another view. The semantics would be deleting an artifact generated from the parent view would delete the artifact it owns generated from the subview. In general, "sub" anything in modeling usually comes in owned and non-owned flavors. - If the instances of views are the artifacts generated, what are the instances of viewpoints (Viewpoint is also based on Class)? Since views conform to viewpoints, and both are classes, I would figure anything conforming to a view (instances of a view) would conform to the viewpoint. This is the same semantics as generalization (all instances of a subclass are instances of its superclasses). It means the Conform stereotype should be based on generalization. From: "Chonoles, Michael J" To: "sysml-rtf@omg.org" CC: "Watson, John" Subject: Ballot 6 , 18719 View/Viewpoint Thread-Topic: Ballot 6 , 18719 View/Viewpoint Thread-Index: Ac5l7inpY/73dX8lTHihQA8ZFh+S7g== Date: Mon, 10 Jun 2013 15:21:28 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.82] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-06-10_03:2013-06-10,2013-06-10,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r5AFMm5j030218 Some questions. 1) What was the motivation for preventing View from owning comment elements. Practically, when presenting a view to stakeholders, we want them to be able to place comments (questions, tbd, action items, etc.) on the elements. 2) It is unclear whether a view can reference SysML diagrams/tables. This was unclear previously; it would make sense to make this clear now. 3) In table 7.1 the replacement row for Viewpoint has room for only 1 stakeholder. However, the definition for Viewpoint in Section 7.3.2 allows for multiple stakeholders. 4) I'm not sure why a view can only conform to one viewpoint. I have many circumstances, where there is view (such as a particular Requirements Deliverable) that must conform to 1) Requirements Deliverables, 2) Project X artifacts, 3) Classified Artifacts (and perhaps more). 5) Won't some of the figures, such as Figuer c.3, need to change based on this change Michael -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Monday, June 10, 2013 9:56 AM To: sysml-rtf@omg.org Subject: EXTERNAL: Re: Ballot 6 checkin, 17584, OCL P.S. Just wanted to check if the OCL knowledgeable see any problems with this on Parameter: inv: (type.isKindOf(DataType)) implies (effect = null) I heard maybe the type should be checked for having a value when applying isKindOf, but if having no type causes the antecedent to be false, then it would be doing the right thing. Conrad