OMG SysML Portal

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
----
\\

[[auto-view_generation_working_group|Auto-View Generation Working Group home page]] - [[requirements|Requirements]] - [[usecases|Use Cases and Scenarios]]

----
\\
This page is a rough draft.


====== Architectural Decisions ======
*view centric over document centric -> views and viewpoints over documents and sections
*method - > reproducible
*viewpoint composition ->
*libraries - > reusability

====== Assessment of SysML 1.3 Against View-Viewpoint ======
*Write up general issue of scalability
** viewpoint methods aren't executable
** import not scalable. issue is how to specify the argument (model elements as input to) the viewpoint method
*** describe alternatives: method library vs viewpoint library

====== Priorities ======

^Priority^Issue^Description^Rationale^Possible Fixes^Notes^
|Now|Property Ordering|SysML lacks ordering of part properties within multiplicities|TBD|TBD|cant order individual elements of the multiplicity. cant constraint the multiplicity property. UML spec allows for property order so this is maybe a tool bug rather that UML/SysML issue|
|Now|Viewpoint Model ELements Are Tags|viewpoint properties are tags - > need ot be props|TBD|TBD|TBD|
|Now|Methods are not behaviors|The Viewpoint Method is a simple tag. It needs to become a classifier behavior.|TBD|TBD|TBD|
|Now|Query Instead of Import|view imports elements from model. This is not scalable. |TBD|TBD|Consider replacing 'view imports model elements' with 'view queries model'. (cldelp-This could also be Viewpoint Queries.)|
|Now|Diagrams should be allowed to be Views|Currently diagrams are not defined as views. It should be possible to distinguish between diagrams that are views and diagrams that are just diagrams|TBD|TBD|TBD|
|Future|TBD|composition of behavior classes and blocks not clear. need to be able to compose parametric constraints onto behaviors|TBD|TBD|TBD|
|Future|TBD|no way to make a relationship such that a parameter is set to be assigned a model element|TBD|TBD|TBD|
|Future|TBD|no way to set a trajectory of specific values|TBD|TBD|TBD|
|Future|TBD|view is expressed in terms of one to many artifacts such as diagrams, tables, etc. |TBD|TBD|considering adding a concept of a view artifact, where a view is composed of view artifacts|
|TBD|TBD|TBD|TBD|TBD|TBD|

====== Principles ======
^Principle^Definition^Rationale^Impact^
|parsimony|TBD|TBD|TBD|
|grounded in fundamentals of MBSE - wymore|TBD|TBD|TBD|

====== Qualities ======

^Quality Attribute^Description^Metric^Notes^
|expressivity/communicability|TBD|TBD|TBD|
|extendability|TBD|TBD|TBD|
|composability|TBD|TBD|TBD|
|reproducibility|TBD|TBD|TBD|

====== View Generation Notes ======
From Cory Casanave in an email to Len Levine on December 7, 2012: The following is the in-progress definitions being developed as part of the MDA guide:

View and Viewpoint
A viewpoint specifies a reusable set of criteria for the construction,  selection, and presentation of a portion of the information about a system, addressing particular stakeholder concerns.  The by far most widely used construct since 1976 is the SQL view construct.

A view is a representation of a particular system that conforms to a viewpoint.  We could, for example, have a view representing the security concerns of a payroll system.

For example, if we are creating a model information of a system that shares information there may be views for:
  * The meaning of the information to be shared
  * How the information is to be structured when shared
  * What information is to be shared with whom and under what conditions
  * The protocol by which the information consumer requests or is sent the information
  * What technology is used to actually transmit the information (in a technology model, not in a conceptual model)
  * How the information is protected during transmission
  * How we identify the parties involved
  * How the shared information is derived from our internal data

Note that the above views are interrelated, that is there are connections between them that are contained in the ground level, the model and the metamodel but that may or may not be visible in any one viewpoint.

---editorial---
While not specifically addressed, I think the intent is that a diagram is part of (could be all of) a view and that a diagram type is part of (could be all of) a viewpoint.

-Cory
OMG SysML Portal

User Tools

Site Tools

Page Tools
