This proposal describes adding a new UI for model management platforms like the MCF that allow for rapid model data entry by distributed teams directly into the modeling repository. The datagrid must have the kind of rapid interface feedback and scaling tools available in Excel, which will be enumerated later in this description. The goal of this datagrid is to make it the place for engineers to feed data directly into the model and possibly reuse common data elements and share them.
Motivation
When an engineering project reuses data from previous efforts or simply when large quantities of data just need to be entered into the system, existing tools are far too slow. View Editor tables and Generic Tables in Cameo are 10x slower than native Excel for data entry and also cycle through UI state changes while the Excel experience is seamless. This continues to put a workflow and a cognitive divide between model data input and "doing the engineering work."
The capability for this kind of data entry needs to be as ubiquitous as any common deployed tool by IT on institutional computers. This means it is either an MS Office tool (too late) or a web-based capability.
MapleMBSE helps with the data entry, but its ideal use cases would be for where computation and data management is required.
Guide-Level Explanation
The datagrid is an enhanced version of the Generic Table in cameo. Rows correspond to specific model elements of a given metatype, stereotype, or that pass a particular test (for example, the closure of the self.general attribute includes a given type - in other words a direct or indirect subtype). Each cell can be one of three types:
The literal value of a property whose name matches that of the record (e.g., an attribute value)
The literal value of a property of a model entity navigated from the row (a la a Powered Equipment List where the row is a component, the column names a particular mode usage in the self.modes collection, and the property is Current Best Estimate, which is noted as a nesting column header)
A reference to another modeling element from a reference attribute (e.g., an element's owner) - aka "relationship ends"
Navigating the datagrid is simple. Tab, Shift-Tab, arrow keys, and the enter key navigate horizontally. Arrow keys, Shift-Enter, and Ctrl-Enter navigate vertically.
Cell entries that are repetitive can be filled through dragging cell cursors like Excel.
When relationship end cells have multiple values, they can displayed multiple ways
As chip UI elements with the cell with delete "X" for removal
As generators of additional rows, where the value then becomes the row starter for a logically nested table
Signatures can also be used to abbreviate model element references (e.g., in a "part properties" listing under a Block, the value can be represented as "front : Wheel" to indicate the property name and type together; is property and type names are the same this can be collapsed into a single name) as is found useful.
Relationship end cells can have values added through auto-complete widgets.
Rationale
A purpose-built table UI is necessary because a number of idioms that non-modeling trained engineers use have a somewhat regular structure than can be translated into table view idioms. However, this requires that the table is model aware, not just something to be post-processed later. For example, the use of nesting in rows to essentially delineate sub-tables within a given table is something that is hard to post-process from Excel but may be enhanced with UI hints.
Also, a desire here is to have the table provide views of the same element. A given component may show up differently in a Bill of Materials, a mass accounting list, a communications channel tracker, and so on. This typically leads to a proliferation of spreadsheets with similar data but with enough differences to thwart naive attempts at scripting.
Summary
This proposal describes adding a new UI for model management platforms like the MCF that allow for rapid model data entry by distributed teams directly into the modeling repository. The datagrid must have the kind of rapid interface feedback and scaling tools available in Excel, which will be enumerated later in this description. The goal of this datagrid is to make it the place for engineers to feed data directly into the model and possibly reuse common data elements and share them.
Motivation
When an engineering project reuses data from previous efforts or simply when large quantities of data just need to be entered into the system, existing tools are far too slow. View Editor tables and Generic Tables in Cameo are 10x slower than native Excel for data entry and also cycle through UI state changes while the Excel experience is seamless. This continues to put a workflow and a cognitive divide between model data input and "doing the engineering work."
The capability for this kind of data entry needs to be as ubiquitous as any common deployed tool by IT on institutional computers. This means it is either an MS Office tool (too late) or a web-based capability.
MapleMBSE helps with the data entry, but its ideal use cases would be for where computation and data management is required.
Guide-Level Explanation
The datagrid is an enhanced version of the Generic Table in cameo. Rows correspond to specific model elements of a given metatype, stereotype, or that pass a particular test (for example, the closure of the self.general attribute includes a given type - in other words a direct or indirect subtype). Each cell can be one of three types:
Navigating the datagrid is simple. Tab, Shift-Tab, arrow keys, and the enter key navigate horizontally. Arrow keys, Shift-Enter, and Ctrl-Enter navigate vertically.
Cell entries that are repetitive can be filled through dragging cell cursors like Excel.
When relationship end cells have multiple values, they can displayed multiple ways
Signatures can also be used to abbreviate model element references (e.g., in a "part properties" listing under a Block, the value can be represented as "front : Wheel" to indicate the property name and type together; is property and type names are the same this can be collapsed into a single name) as is found useful.
Relationship end cells can have values added through auto-complete widgets.
Rationale
A purpose-built table UI is necessary because a number of idioms that non-modeling trained engineers use have a somewhat regular structure than can be translated into table view idioms. However, this requires that the table is model aware, not just something to be post-processed later. For example, the use of nesting in rows to essentially delineate sub-tables within a given table is something that is hard to post-process from Excel but may be enhanced with UI hints. Also, a desire here is to have the table provide views of the same element. A given component may show up differently in a Bill of Materials, a mass accounting list, a communications channel tracker, and so on. This typically leads to a proliferation of spreadsheets with similar data but with enough differences to thwart naive attempts at scripting.