SysML 1.4 - View and Viewpoint - Example

The third part of the blogpost series about the changes in SysML 1.4 presents the updated concept of view and viewpoints. View and Viewpoint are model elements of SysML since the very first public version 1.0. As you may know SysML was developed based on a request for proposal with a set of requirements. One requirement was about views:

SysML 1.4 - View and Viewpoint - Requirement

SysML 1.4 – View and Viewpoint – Requirement (click to enlarge)

In SysML 1.0 the view and viewpoint concept is consistent with the IEEE 1471 standard (IEEE Recommended Practice for Architectural Description of Software-Intensive Systems) – now the ISO-42010 standard.

The viewpoint specifies rules for constructing a view including a set of stakeholders, their concerns and the purpose to address the concerns. The view is a representation of the system from the perspective of a viewpoint. The following figure shows a simple view and viewpoint example with SysML < Version 1.4:

SysML 1.4 - View and Viewpoint - Exemple before SysML 1.4

SysML 1.4 – View and Viewpoint – Exemple before SysML 1.4 (click to enlarge)

In theory that was a good concept. However I’ve never seen a valuable implementation in practice. You need a tool that generates the real view, i.e. the text document, spreadsheet, etc.. But no such tool was available. All SysML modeling tools have their own way how to generate documents from the model. Without the implementation the modeling of views and viewpoints was not very useful.

SysML 1.4 has an updated concept of view and viewpoints. It is still consistent with ISO-42010 and has a more formalized concept how to generate a view. However the final implementation of the view generation is still out of scope of the SysML specification. The following figure shows a view/viewpoint scenario with the all model elements.

SysML 1.4 - View and Viewpoint - Example

SysML 1.4 – View and Viewpoint – Example (click to enlarge)

With version 1.4 SysML provides a model element for stakeholders. The stakeholder has a name and a list of stakeholder concerns. The concerns are comment model elements. The relationship between the stakeholder and the comments has no notation. The SysML model element stakeholder extends the UML classifier, i.e. a stakeholder could be a special actor as well as a special block. The stakeholder is defined in the context of the view and viewpoint concept. It is not the common stakeholder known from requirements engineering.

Now the SysML model element view extends the UML class. Before version 1.4 it was a special UML package. The view has two derived properties: a list of stakeholders derived from the stakeholders list from the viewpoint and the related viewpoint derived from the conform relationship that relates a view to a viewpoint. Conform extends the UML generalization relationship. That means a view is a special kind of a viewpoint and inherits all the features of the viewpoint. The view represents the physical artifacts of the view for example a text document, spread sheet or slide presentation.

The version 1.4. viewpoint has some updated properties according to version 1.4:

  • concernLIst is a list of concerns of the stakeholders that should be addressed by this viewpoint. Each concern is modeled by a comment. Again there is relationship notation defined between viewpoints and comments.
  • concern is a derived property that lists the bodies of the comments of the concernList. I wasn’t able to activate that property in my modeling tool. Therefore it is not shown in the diagram above. However it modeling tool already shows the comment body in the concernList property.
  • method is a derived property that shows the behavior that is used to create the view. It is derived from the behavior of the constructor of the viewpoint (see below).
  • language specifies a list of languages used to express the models that represent content which is represented by the view.
  • presentation defines a prescription of the format and style of the view.
  • stakeholder is a list of stakeholders whose concerns are to be addressed by the view.

A viewpoint must have a View() operation with applied stereotype Create. The method of the operation is a list of behaviors. For instance it could be a opaque behavior that specifies the creation of the view in a modeling tool specific language.

The expose relationship relates a view to model elements that are passed to the View() constructor when it is invoked. The model elements are the entry point for the model query that is typically part of the View() implementation to query data from the model for the view.

Finally I show you a simple example how to use the new view/viewpoint in a modeling tool. For instance the Cameo Systems Modeler from NoMagic provides a report generator based on the SysML 1.4 view/viewpoint concept. The tool provides some predefined implementations for the View() operation of the viewpoint. The following model specifies a view with a short textual introduction and a list of the content of the FFDS model.

SysML 1.4 - View and Viewpoint - Example Cameo Systems Modeler

SysML 1.4 – View and Viewpoint – Example Cameo Systems Modeler (click to enlarge)

The preview shows the text and a table of content of the FFDS model with the name and the documentation of the packages on the next level.

SysML 1.4 - View and Viewpoint - Preview

SysML 1.4 – View and Viewpoint – Preview (click to enlarge)

These are very basic views and viewpoints. With them you can create your own toolbox of predefined viewpoints and create complex views/viewpoints by combining them.

Post a Comment