SYSML14 — View and Viewpoint Construction Limitations (from Issue 18391 c), d), e) and g))

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).

summary of the proposed changes in this resolution include:
1. Extend View from Class instead of Package to enable means for referencing
views.
2. Add a presentation property to Viewpoint whose value(s) is/are the presentation
format for the view.
3. Establish a relationship between an instance of a view and an instance of the
model that the view is intended to represent.
General Background
It should be noted that SysML’s choice of Viewpoint and View is consistent with
industry standard definitions, and should be maintained. The intent of this resolution
is to preserve the basic view and viewpoint concepts, and only make changes
needed to refine the modeling elements based on industry experience applying these
concepts.
Expose
The expose relationship was added to address scalability issues with package import
as described in part b of this issue. Package import is not sufficient for dealing with
large models because it may require a large number of import relationships to identify
the imported elements in the package serving as a view.
The expose relationship resolves this issue by relating the view only to model
elements that correspond to access points to initiate the model queries performed by
the viewpoint method. The viewpoint method determines what additional elements or
other data will actually be part of the view relative to this access point.
The expose relationship extends generalization. This enables the viewpoint method
to be inherited by the view so that it represents the constructor of the view.
View Class
The change of view from a package to a class resolves part c of this issue. It may be
necessary or desirable to reference other views in order to construct a view that
conforms to a viewpoint. This results in a hierarchy of views that provides an ordered
traversal through the views. This ordering is necessary to understand the story the
views tell about the model.With view as a class, properties can be made for these
view references allowing the distinction of the different view trees within the hierarchy. Additionally, view as a class supports the concept that a view instance is a
specific artifact that is presented to the stakeholder.
Presentation Attribute
The presentation property was added to address issue a). In many organizations,
stakeholders or internal standards may require explicit rules for presentation such as
specific styles, colors and fonts defined in a stylesheets, file formats, and other
specifications. This property is intended to provide a flexible approach that supports
this need..