Viewpoints and Views in SysML

1. Viewpoints and Views in SysML Dr Graham Bleakley graham.bleakley@uk.ibm.com

2. Agenda • Drivers • Separation of concerns • Viewpoint and view in MODAF, DoDAF and UPDM • Issues with viewpoint and view in SysML • Initial thoughts on solutions

3. Drivers for this discussion • DoD would like UPDM group to define Viewpoints and Views • System developers would like UPDM group to define Viewpoints and Views • Issue one, they are talking about different definitions for viewpoint and view • DoD • DoD lexicon historically (DoDAF 1.0/1.5), viewpoint is seen as a collection of views that address a concern, i.e. systems, operational etc. • Views considered to be diagrams • Not thinking about information/data aspect of what is on the diagram • System developers • Much more mature, they are thinking about viewpoints and views based upon standards such as ISO 1471 and its successor ISO 42010 • Thinks about a data/model centric approach • DoDAF 2.0 takes an approach based upon ISO 42010 for PES (although not well enough defined) • MODAF/MODEM takes an approach based upon ISO 42010

4. Identify stakeholder groups • Three primary sets of users of architectures and models • Creators:- Architects, Systems Engineers, Software Engineers etc • Build models for various reasons • Viewers:- Reviewers, Decision Makers • Primary use of the model is to understand what is being expressed • Comment and make judgement on it • Analyzers:- Modellers, Architects, Information analysts • Carry out Simulation, • Information analysis across the model • Impact analysis • Gap analysis • Inferred and implicit relationships of information • Some people fit into all three roles

5. Separation of concerns • Simple definition • Viewpoint:- the specification of the presentation of a set of elements from a model used to address a stakeholders needs and concerns • View:- Is the set of information and its visualization such that it conforms to the viewpoint to address the stakeholder needs and concerns • Means of visualizing the information can be achieved in a number of ways • Diagram (as created by the creator), OV-2, SV-1 etc. • Table of Matrix (filter on relationships), OV-3, SV-6, SV-7, SV-5 • Derived or auto generated from model, CV-3, CV-5 and PV-2 • Viewpoints and views are about separation of the creation of the model from the use of the information in the model • I can appreciate a viewpoint could be used to provide guidance on creating a diagram that can be used to conform to a view • But a diagram is not a view it is a means of visualizing the information • Issue is that historically Creators have informally been follow viewpoint definitions and create diagrams that conform to viewpoints and Viewers and Analysts have called these views • Issue with use of viewpoints and views in DoDAF 1.0-1.5

6. Viewpoint and View in IEC 42010 • Conceptually nothing wrong with ISO 1471 or its successor ISO 42010 • http://www.iso-architecture.org/ieee-1471/index.html • Issue is that they are too abstract • Very easy to specify • Very hard to implement • Unless you want to do a lot of work by hand • Each viewpoint relates to types of model • Each view relates to models • Diagrams are not models, there are means of visualizing, analyzing or creating the information relationships for a model • Diagrams can be part of view

7. Views in MODAF • MODAF uses views as a filter of information in the model • Initially based on ISO 1471 • Each window a separate view or product • Model Elements internal to cube used by multiple views • Views can act as • Filters on the information in the architecture (OV-3, SV-5) • Diagrams allowing you to create the information that populates the architecture (SV-1, OV-2) • MODEM uses ISO 42010 with some extensions, need to review

8. Views and Viewpoints in DoDAF • Historically Viewpoint has been seen as collection of views that address a concern • Has lead to views being seen as diagrams • DoDAF 2.0 the terms view and viewpoint are still used in this way but there is also a flawed relationship with ISO 1471/42010 • Physical Exchange Mechanism (PES) • PES is not about exchange • PES is about viewing sets of information in that address the concerns of viewers analysts • The PES XSD schema can be considered to be a set of 52 viewpoint specifications • Each viewpoint specification is based upon a very large set of types of elements defined in DM2 monster matrix • Many of these types of element are seen in many views • An instance of a PES file is set of views containing “models” • A model being a very large set of elements and diagrams • You cannot sensibly put all the types of elements that should appear in DM2 view on a single diagram, it would loose any understandability • The models are stovepiped, they exist as separate entities • Many of the models contain 60-70% of the complete architecture, just a slightly different 60-70 %

9. Viewpoints and views in UPDM • The terms are defined in UPDM as a hash up between how DoDAF and MODAF use the terms informally and how SysML uses them • We try to separate the informal presentation way in which the terms Viewpoint and view are used in MODAF and DoDAF from the formal terms in ISO 1471 and SysML • Why we use the term products • We define products as having types of elements that appear on them. • Addresses the concerns of the creator • Currently non-normative • We are considering making this product definition more guided and definitive so:- • Creators have a common understanding of what should appear on the products • Tool vendors have a common palette to work with • Starting point for diagram definition • It is not view and viewpoint definition • We need to base this on the specifications we have available to us in OMG • Which means SysML, SysML viewpoint and view are currently not formal enough

10. Viewpoint and View in SysML 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. Attributes stakeholders: String [*] Set of stakeholders. purpose: String The purpose addresses the stakeholder concerns. concerns: String [*]The interest of the stakeholders. languages: String [*]The languages used to construct the viewpoint. methods: String [*]The methods used to construct the views for this viewpoint. Constraints [1] A viewpoint cannot be the classifier of an instance specification. [2] The propertyowned Operation must be empty.[3] The property owned Attribute must be empty. • 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. • Attributes • viewpoint: ViewpointThe viewpoint for this View, derived from the supplier of the «conform» dependency whose client is this View. • Constraints • [1] A view can only own elementimport, packageimport, comment, and constraintelements. • [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. The precise semantics of this constraint is a semantic variation point.

11. Viewpoint and View in SysML • Examples • Viewpoint is a class • View is a package that • Conforms to the Viewpoint • Imports explicit elements

12. Issues with Viewpoint and View in SysML • Two main issues that I see • Conforms property is a string • Free text, no way to formally define the types of elements that should be imported into a view • Needs to be formally defined to be of value in automating the generation of views • How it is applied is a “Semantic Variation Point” • Explicit use of import dependency • Because you have no formal way of defining what should be in a view you do not have a way of automatically creating the import relationships • Need to create these by hand • In DM2 lots of redundancy as many views in DM2 use the same elements and many views populated by 60-70% of the types of available elements for conformance • Not practically scaleable for large architectures because of these issues • I have seen customer models with hundreds of elements and tens of DoDAF SV-4s for example • Question do you have a view for each SV-4 or package them together ?

13. Things to consider for solutions • To enable viewpoints and views to be efficient there needs to be a way define the means of conformance and presentation a lot more rigidly so that tool APIs can automate a lot of the work. • Needs to be standardised if defining sets of common views and viewpoints as part of a standard so we can all use them • Conforms statement needs to consider formalising the expression of • Scope of information • Packages, Diagrams, Specificity etc. • Presentation format • Diagram, • Table, Matrix • Generated from model • Types of information and elements • Degrees of freedom • Sets of related elements • E.g. Performer, related to its Activities by ActivityPerformedByPerformer (OV-2) • You would not smother your OV-2 with activities and dependencies

14. What’s being done about it • Viewpoint/ view working group as part of the SE DSIG • About automated generation of documents from Viewpoint specifications • A document can be considered to be a view on the model • http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-autoview:auto-view_generation_working_group • Being led by Chris Delp • He has formalised the sort of information required to generate views of models as HTML and other formatted documents • There is more to it than you think • http://www.omgwiki.org/OMGSysML/lib/exe/fetch.php?cache=cache&media=http%3A%2F%2Fdoc.omg.org%2Fsyseng%2F2012-06-06 • To make viewpoints and views work all three of the main stakeholder groups need to change they way they think about modelling and architecture