SYSMLR — 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.)
The viewpoint method does not include provisions for specifying the language for the methods. Adding the ability to designate the language would clarify viewpoint.
b) 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.
c) 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.
d) 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 described below.
In a simple example, different subviews may correspond to different sections of a 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 this example, 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.
e) 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.
f) 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.
g) 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).

Defer

Postponed to the next RTF