Click to edit Master title style Sys ML

Click to edit Master title style Sys. ML 2. 0 Concept and Needs for Visualization 03/22/2017 OMG Q 1 Meeting Reston, VA 1

Services Click to edit Master title style • Primary Service • “Create, read, update, delete, and execute viewpoints” • Other Related Services • “. . . Model queries. . . ” • “. . . Model execution. . . ” • “. . . View changes. . . ” • “. . . View/execute links to other data. . . ” • . . . Nearly all others (specialized queries) 2

High-Level Needs Click to edit Master title style • Viewpoint Definition • Data Model + (Define objects, attributes, source formats) • Viewpoint Types (Sys. ML Standard, Geometry, custom) • Persistence • View Definition • • • View Element Definition (Define, map, relate) Layout Definition View Behavior (layout, execution, interaction) View Navigation Persistence 3

Visualization Concept Diagram Click to edit Master title style 4

Click to edit Master title style BACKUP 5

Requirement Organization Click to edit Master title style • Data Model • Requirements for data model, meta model, attributes, types, etc. • Data Sources • Requirements for sources of data to be used in model visualization • Visualization Definition • Requirements for rules for rendering and interactivity defined relative to the data meta model within a viewpoint • Viewpoint Definition • Requirements for model viewpoints including Sys. ML standard and user-defined views • Views • Requirements for views (executed viewpoints) • View/Viewpoint Persistence • Requirements for the persistence of viewpoint and view data and meta data 6

Requirements – Data Model Click to edit Master title style • Driving Requirement(s) • Model data and meta shall be accessible for viewpoint usage • Users shall be able to define viewpoints using both relational and graph-based data models UID Short Name 2. 1. 1. 1 Data Model Objects 2. 1. 1. 2 Data Attributes 2. 1 Relational Data Models 2. 1. 2. 2 Graph Data Models Requirement Text The viewpoint shall be able to define data model object types within the metamodel The viewpoint shall be able to define data attributes describing the data model objects The viewpoint shall be capable of defining viewpoints using relational data models The viewpoint shall be capable of defining viewpoints using graph data models Type Level Requirement 4 7

Requirements – Data Sources Click to edit Master title style • Driving Requirement(s) • Viewpoints definition shall be able to use a variety of data sources • Viewpoint definition shall be aware of data source location and authorization UID 2. 2. 1. 1 2. 2. 1. 2 2. 2. 1. 3 2. 2. 1. 4 2. 2. 2. 3 Short Name Requirement Text The viewpoint shall be able to define transformations to the data metamodel Normalized Data from normalized data sources (i. e. relational databases like Oracle, DB 2, Sources My. SQL, etc. ) Non-normalized Data The viewpoint shall be able to define transformations to the data metamodel Sources from non-normalized data sources (i. e. graph databases) Serialized Data The viewpoint shall be able to define transformations to the data metamodel Sources from serialized data sources (i. e. XML, CSV, etc. ) The viewpoint shall be able to define transformations to the data metamodel Object Data Sources from object data source (i. e. , in-memory objects) Data Source Location The viewpoint shall be able to define the location (e. g. , URL) of a data source Data Source The viewpoint shall be able to define user authentication and authorization Authorization properties for a data source Type Level Requirement 4 Requirement 3 8

Requirements – Visualization Click to edit Master title style Definition • Driving Requirement(s) • Visualization definition shall include a variety of forms including text, document, serializations, etc. • Visualization definition shall include interactive, comparative and executive behavior UID 2. 3. 1. 1. 1 2. 3. 1. 1. 2 2. 3. 1. 1. 3 2. 3. 1. 2 2. 3. 1. 3 2. 3. 1. 4 2. 3. 2. 1 2. 3. 2. 2 2. 3. 3. 1 2. 3. 3. 2 Short Name Rendered Object Requirement Text Type Visualization definitions shall define rendered objects. Requirement Diagram visualization definitions shall be capable of defining the following graphical elements: nodes, edges, Diagram Object Definitions ports, full drawing Requirement Diagram visualization defintions shall be capable of specifying a default layout style, defining layout properties, Diagram Layout Definitions and constraining the relative and aboslute positions of rendered objects within the diagram Requirement Diagram visualization definitions shall be capable of defining ownership relationships among rendered objects Diagram Topology Definitions within the diagram (e. g. nodes own ports) Requirement Textual visualization definitions are of special interest to the SME. The rendered objects of a textual visualization Textual Rendered Objects definition are unicode characters and are presented in a human-readable form. Requirement Model Serialization Rendered Model serialization visualization definitions are of special interest to the SME. The rendered objects of a model Objects serialization visualization are presented in a machine-readable form for tool interoperability. Requirement Document visualization definitions are of special interest to the SME. The rendered objects of a document visualization are a collection narrative text, diagrams, tables, and/or rendered objects of other human-readable Document Rendered Objects types supporting a specific business or engineering objective. Requirement Visualization definitions shall define interactive behaviors related to the visualiztion rendering (e. g. change color, View Interactive Behaviors layout, zoom, sort table rows, resize text, add/remove layers, etc. ) Requirement Visualization definitions shall provide interactive behaviors related to the model data (e. g. perform validation and Model Interactive Behaviors highlight results, analyze view data, modify data attributes) Requirement Comparison Visualization The visualization definition shall indicate whether comparison of (and revealing differences between) model Capability versions is supported by this visualization. Requirement Execution Visualization The visualization definition shall indicate whether dynamic representation of model execution is supported by this Capability visualization. Requirement Level 3 5 5 5 4 4 4 4 9

Requirements – Viewpoint Click to edit Master title style Definition • Driving Requirement(s) • Definition of viewpoints shall include Sys. ML 1. X standard views, with the addition of a new viewpoint for geometric views • Definition of viewpoints shall include facilities for user-defined and domain-specific views • Viewpoints shall be relatable to other viewpoints (semantic pan) UID 2. 4. 1 2. 4. 2 2. 4. 3 2. 4. 4 2. 4. 5 Short Name User-Defined Viewpoint Definition Domain-Specific Viewpoint Definition Sys. ML 1. X Standard Viewpoint Definitions Sys. ML 2. 0 Geometry Viewpoint Definition Viewpoint Relatability Requirement Text Type An individual shall be capable of defining a viewpoint to meet his or her specific needs, containing one Requirement or more uniquely required data models, data sources, and/or visualization definitions. Domain standards groups shall be capable of defining a set of viewpoints to meet common needs for users within the domain, containing one or more commonly required data models, data sources, and/or Requirement visualization definitions. The Sys. ML specification shall continue to provide a set the Sys. ML 1. X standard viewpoints containing the standard Sys. ML metamodel and visualization definition required to generate the standard Sys. ML Requirement diagram types. Level 3 3 3 The Sys. ML specification shall provide a new Sys. ML standard viewpoint providing the ability to visualize Requirement 3 -D geometric definition for Sys. ML elements 3 The Sys. ML specification shall provide a mechanism to map Sys. ML-defined viewpoint elements to user. Requirement defined and domain specific viewpoint elements 3 10

Requirements – Views & Click to edit Master title style Persistence • Driving Requirement(s) • Viewpoint shall be executable as static and dynamic views, including navigation between executable viewpoints (semantic pan) • Viewpoints shall be capable of persisting (user-defined modifications to viewpoint definition) • Views shall be capable of persisting (user-defined modifications to views like filtering querying, etc. ) UID 2. 5. 1 2. 5. 2 2. 5. 3 2. 6. 1 2. 6. 2 Short Name Requirement Text The viewpoint shall be executable to export static views. A static view does not Static Views implement any interactive behaviors defined on the viewpoint. Dynamic The viewpoint shall be executable to generate dynamic views. A dynamic view Views implements the interactive behaviors defined on the viewpoint. Views shall be capable of navigating to other views based on view element View relations (e. g. from a BDD to a related IBD to a related AD based on related Navigation elements Viewpoint definitions shall have the capability of being persisted (i. e. saving, Persistence storing, recalling) Views (both originally defined and user modified) shall have the capability of Persistence being persisted Type Level Requirement 3 Requirement 3 11

Interfaces Click to edit Master title style • Model Construction • Provide modified data and meta data from executed views • Model Analysis • Receive analysis/query data for view/viewpoint definition and execution • Provide analysis/query viewpoint definition • Provide analysis/query view execution • Model Management • Receive authentication and access information services • Receive model data and meta data (incl. version, in-work, etc. ) via standard Sys. ML meta model and extensions • Receive managed viewpoint definition data • Receive managed view execution data • Provide view/viewpoint definition data 12

Click to edit Master title style BACKUP 13

Concerns/Comments from Click to edit Master title style Coronado Concrete syntax requirements. Sys. ML v 2 shall: • Provide a flexible view and viewpoint capability that includes graphical, textual, tabular, and numerical presentation methods [2. 3. 1] • Provide support for composite viewpoints and navigation between view [2. 4. 1, 2. 4. 2, 2. 4. 5, 2. 5. 3] • Provide standard viewpoints and views for Sys. ML v 1 diagrams (assists transition from v 1 to v 2) [2. 4. 3] • Provide a standard mapping language between concrete syntax and abstract syntax [2. 2. 1] • Provide a standard graphical concrete syntax that maps to the abstract syntax [2. 3. 1] • Provide a standard textual concrete syntax that maps to the abstract syntax [2. 3. 1] • Provide ability to specify domain specific concrete syntax (e. g. , symbol sets) that maps to the abstract syntax [2. 4. 1, 2. 4. 2] • Provide a simple geometric view as a standard diagram* [2. 4. 4] • Provide a standard viewpoint library (platform independent model with platform bindings) [2. 2. 1] • Provide diagram interchange and/or exchange of the viewpoint method to regenerate the view [2. 2. 1, 2. 6. 1] • Provide persistent views to support documentation and reports [2. 3. X, 2. 6. 2] • In addition, Sys. ML v 2 should provide visualization services such as support for auto-layout, dynamic, interactive visualization (e. g. , user select scope of model, filters, layers, etc. ), as well as manual diagram layout capability. The ability to specify diagram layers that consist of a group of diagram elements which can be displayed (e. g. , turn on or off, assignment of colors or offsets, etc. ), is considered an essential feature of Sys. ML v 2 views. [2. 3. 2. X] 14

Original Sys. ML Click to edit Master title style v 1. x Limitations • Separation of Model Construction from Visualization • Diagram construction left to modeler • Model elements can be removed, but added elements cannot be automatically added to diagrams • Some tool capabilities to auto-create, but not necessarily rule-based • Specification of Sys. ML Diagrammatic Views • Appearance of Sys. ML diagrams is fixed with no facility for user-defined rules • Modelers sometimes make modeling choices to accommodate immediate needs, resulting in more work later or deferring robust modeling • View Construction and Layout • Layout of diagram elements manual requiring manual maintenance • Facility for “semantic zoom” • In-Work, Changed Data and Model Compare • The current spec is silent on visualizing changes and differences between model baselines 15

Capabilities to be required? Click to edit Master title–style • View Definition • Highly flexible viewpoint specification • Data query/filter capability • Data transformation • Interactive behaviors • Standard Sys. ML diagram type definitions • Extension for user-defined and domain-specific visualizations • View Generation • Defined graphical and layout styles for the nine core Sys. ML diagram types • Extensions for graphical definitions of diagram objects (nodes, edges, connectors) • Extensions for diagram layout and style • • • Defined extension framework for visualization Semantic filter, zoom and pan capability Static and dynamic view generation Facilities for compare/differencing views of model data (element, diagram and data set levels) Capability to visualize model execution • View Export • Static and dynamic view export • Document generation 16

Concrete Syntax & Standard Click to edit Master title style Diagrams • Requirement – • The Sys. ML specification shall provide means to visualize the standard Sys. ML diagram types. • Considerations/Approaches – • No longer specify standard Sys. ML diagrams and syntax, instead providing only the abstract capability to define viewpoints that are known to be a superset of those required for standard diagram types. • Specify only Sys. ML diagram types (viewpoints), but allow user-defined syntax within the constrains of the specified viewpoints • Specify some/all Sys. ML diagrams with a set of defined executable viewpoint, providing set of visualization definitions that result in diagrams that look like the current concrete syntax of Sys. ML 1. X (Somewhat dependent on formalism connection to UML) • Maintain current specification of Sys. ML diagrams and syntax, leaving implementation of the concrete syntax within a viewpoint unspecified. • Recommendation – • Specify standard viewpoints and syntax for the standard 9 Sys. ML diagram types 17

User-Defined Diagrams Click to edit Master title style • Requirements – • Current requirements only specify requirements to map data, define viewpoints and generate views. • Examples – • “The viewpoint shall be able to define data model object types within the metamodel” • “The viewpoint shall be able to define data attributes describing the data model objects” • Considerations/Approaches – • Specify additional (domain-specific) diagram types with Sys. ML 1. X-style concrete syntax • Specify additional diagram types with standard executable viewpoints • Leave domain-specific extensions abstract, leaving both concrete syntax and viewpoint implementation to the user or future dependent specifications. • Recommendation – • Leave extensions abstract. Only specify mechanisms for mapping, view definition and view generation. 18

Visualization for Geometry and Click to edit Master title style States • Scope – • “Light” visualization of geometrical constructs (boxes, cones, spheres, etc. • Apply geometries for states (instance specs? ) • Not to replace visualizations of 3 D geometries from Mechanical domain • Requirements – • Currently, none • Considerations/Approaches – • Continue to NOT specify constructs for basic geometries • Require facilities for capturing and rendering basic geometries (Credit: AGI, Inc. ) • Recommendation – • Enhance the language (along with standard units and measures) to include basic geometry for visualization Artist concept of Juno. (Credit: NASA/JPL) 19

Pallet Click to edit. Elements Master title style and Presentation • Scope – • Presentation of pallet in tools, not inclusive of defined syntax • Elements, meta data, etc. (most tools do this today) • Requirements – • Currently, none • Considerations/Approaches – • Specify (prescribe) pallet and standard presentation of syntactical elements for use in SME • Leave presentation of syntactical elements to vendors • Recommendation – • Continue to leave implementation of syntactical elements to implementation of language (vendor-defined) 20