Coder Social home page Coder Social logo

gtri / rapid-modeling-tools Goto Github PK

View Code? Open in Web Editor NEW
20.0 5.0 6.0 7.53 MB

Model Based Systems Engineering productivity tool to automatically create and manage changes in Cameo MagicDraw models utilizing user-defined modeling patterns.

License: BSD 3-Clause "New" or "Revised" License

Batchfile 0.08% Shell 0.25% Python 81.76% Groovy 17.91%
cameo mbse modeling-experts model-based-systems-engineering productivity-tools ingrid modeling magicdraw cameo-macro cameo-plugin

rapid-modeling-tools's Introduction

Coverage Status

Rapid Modeling Tools

Why Was This Tool Made?

Rapid Modeling Tools (RMT) capitalizes on the wealth of system model information described in a small number of common modeling patterns, from a modeling structure perspective. After identifying a common modeling pattern, the systems engineering task becomes that of a data entry problem resulting in many systems engineering products capturing data in spreadsheets. Spreadsheets alone lack the structure to mark differences in the kinds of information captured (components vs. functions), readily apparent to computers or even non-subject matter experts. Meanwhile, subject matter experts endow the data with semantic annotations without understanding how to express those annotations through the data structures. Thus, RMT seeks to address these issues by combining the data collection, semantic annotation and model creation into one workflow. Inspired by the approach taken by the Maple MBSE tool and the Excel Import in Cameo Systems Modeler, RMT collects data from subject matter experts and non-subject matter experts in the form of an Excel spreadsheet and then creates a fully formed system model in the MagicDraw/Cameo Systems Modeler authoring tool.

Commonly on MBSE projects, modeling professionals find themselves overwhelmed by the volume of information to capture, spending inordinate amounts of time transcribing those data. Ultimately, hurting the productivity of the team and preventing them from taking full advantage of their models; preparing queries and reports to support the larger engineering team. Automating the most straightforward and voluminous parts of the data wrangling effort, collecting and structuring the data according to common modeling patterns, allows the modeling experts to focus on best uses of those data.

If Inspired by Commercial Tools, Why Make a New One?

Primarily because it involves filling in gaps left behind by existing tools.

For one - Maple MBSE does not do comparisons between baseline models and updates on its own. It relies upon the facilities of the Teamwork Cloud or other modeling tools. Having Ingrid perform the change calculations makes it independent of the modeling tool used. It should be compatible with Cameo, Integrity Modeler, Rhapsody, Papyrus, or any other modeling tool. This also allows for engineers that do not have access to any of these tools to act as configuration managers to check that the collected and updated data are ready to go into the model.

For another - Cameo importers work well with string or value fields but do not handle importing the connections between modeling elements gracefully. Thus, making complete model updates requires additional effort. Here we can point out that the existence of the Excel and CSV imports lead the Ingrid team to de-emphasize bulk loading of these values and focus on the development of importing model elements and their links to each other.

About

RMT affords the engineer SME the ability to quickly add, update, or delete design information via a spreadsheet interface which is converted to a set of instructions generated by the ingrid component of RMT. RMT consists of two seperate components:

  • ingrid is a python application which translates spreadsheet data into a set of JSON instructions which are read by the other component of RMT, the player-piano.
  • player-piano is a Groovy script that is used as a macro within the MagicDraw UML/SysML authoring tool to create, modify, or remove model elements based upon the JSON instructions produced by ingrid.

Note: RMT requires MagicDraw or Cameo Systems Modeler. RMT has been tested with Cameo 19.0.

Installation

  • Clone Rapid Modeling Tools
    git clone https://github.com/gtri/rapid-modeling-tools.git
    cd rapid-modeling-tools

    Cloning the repository provides you access to add meta model JSON descriptions and update the player-piano to create novel model elements.

Ingrid

  • Installation simultaneously builds the Application
    • Locate the Application at rapid-modeling-tools/ingrid/dist
    • The Application build process creates the ../dist directory

Windows

  • Install miniconda.
  • Install the Ingrid application
    cd ingrid
    install.bat

Linux / Mac

  • Install miniconda.
  • Install the Ingrid application
    cd ingrid
    bash install.sh
    conda activate model-processing

Additional Details

  • Detailed instructions can be found in the README.md in the ingrid directory for usage with anaconda-project and without anaconda-project

  • CONTRIBUTING.md outlines the expectations for those looking to contribute to Rapid Modeling Tools.

Player Piano

  • With MagicDraw open locate the Tools menu

  • Select Tools > Macros > Organize Macros

  • Select the New button to create a new macro. This will open the Macro Information dialog box.

  • In the Macro Information dialog box, enter the following information:

    • Name: Player Piano
    • Macro Language: Groovy
    • File: browse the file explorer (opened by clicking on the three dots button) to the .../Rapid Modeling Tools/player-piano/player-piano-script.groovy groovy script.
  • Detailed instructions with images can be found in the README.md in the player-piano directory

Getting Started

The ingrid-quick-start provides a basic starting spreadsheet with an example (model included) to show how to calculate model modification commands, both create and compare.

Each of these projects has their own sub README with more details. Please contact [email protected] with questions.

Goals to Bring Rapid Modeling Tools to a 1.0 Release:

Owing to the difficulty of automatic testing with the MagicDraw software the exact MagicDraw versions supported remains unknown. However, we have seen success with Cameo 19.0 and Python 3.6+.

  • Establish Ingrid Nerdman as a MagicDraw plugin
  • Expand coverage of the UML Metamodel in both JSON subgraph definition and Player Piano capability

This tool is intended for MBSE professionals and advanced technical users. Users of this tool set do so at their own risk. Each of these projects has their own sub README with more details. Please contact [email protected] with questions.

Design

Use Cases (purposes)

Rapid Modeling Tools (RMT) are designed to help domain experts and engineers express their efforts in a system model without having to know the intimate details of SysML. The below use cases capture the essence of how domain expert engineers and modeling engineer interact with RMT to support system engineering and domain engineering processes.

UseCases

Components

The RMT is comprised of four major components: an ingestion grid that captures design patterns, a set of model patterns, a translator which matches design patterns to model patterns and creates lists of model transformations, and then the player piano which will execute the model transformations using the Cameo Systems Modeler API. The component hierarchy, and the hierarchy within usage context are shown in the next two images below.

ComponentHierarchy

ComponentHierarchyInContext

Workflows

At a high level, the notional workflow is captured below in a sequence diagram. The domain expert / engineer will inform the modeling expert of the design patterns they wish to capture. The modeling expert will create a way of capturing that in a spreadsheet (ingestion grid) and a modeling pattern file (captured in JSON) that matches that design pattern. The domain expert will then fill out the spreadsheet and give it to the modeling expert. The modeling expert will then use the rest of the rapid modeling tools suite to translate the design patterns captured in the spreadsheet(s) into model transformation lists, then execute those model transformations using the Cameo Systems Modeler built-in API.

HighLevelSequencing

LowLevelSequencing

Item Flows

The items flowing across the components are depicted below. There are four major items that flow using three major formats:

  • Design Patterns <--> Excel Workbook / Worksheets
  • Modeling Patterns <--> JSON
  • Model Transformation Lists <--> JSON
  • Model Transformations <--> CSM (MagicDraw) API Calls

ComponentHierarchyInContext

ComponentHierarchyInContext

Attribution

Developed at Georgia Tech Research Institute by Shane Connelly and Bjorn Cole. Government sponsorship (SOCOM TALOS) acknowledged.

rapid-modeling-tools's People

Contributors

lostindeterminateparticle avatar nrbgt avatar richardwise78 avatar shaneconnelly23 avatar slstarnes avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

rapid-modeling-tools's Issues

pattern "ActorRefiner" does not work

When running test data in Player Piano with the ActorRefiner pattern, stereotypes are not applied to classes and abstractions. The stereotypes are not populated correctly in the output from Ingrid, which appears to be due to an issue with the pattern not specifying stereotypes with a list of dictionaries

Tested using player piano in Cameo Systems Modeler 19.0 SP4
Spreadsheet used as input to Ingrid attached
ActorRefiner.xlsx

Feature Request: Player Piano Does Not Support Multiple Stereotypes

I plan on updating Player Piano to support the assignment of multiple stereotypes. Currently player piano can assign stereotypes using the following format:
"Vertex Stereotypes": { "Item1": [ { "stereotype": "Some Stereotype" } ] }

I plan to add the functionality to support list of stereotypes in the following format:
"Vertex Stereotypes": { "Item1": [ { "stereotype": ["Some Stereotype1", "Some Stereotype2", . . . , "Some StereotypeN"] } ] }

I also plan on adding some additional patterns to support different use cases I need.

  1. A Composition between a Capability Configuration and Organization
  2. A Composition between a Organization and Organization
  3. A Association between a Organization and a System
  4. A Interaction that Owns N Systems

No test coverage for player piano

Working with Player Piano would very much benefit from some kind of automated testing that isn't just running some handmade test data through the macro a few times

pattern "RelSys" does not work

When running test data in Player Piano with the RelSys pattern, the Block stereotype is not applied to classes. The stereotypes are not populated correctly in the output from Ingrid, which appears to be due to an issue with the pattern not specifying stereotypes with a list of dictionaries

Assuming that the pattern is intended to produce use cases linked to a 'related system' with an association, the rest of the pattern seems to be producing a desired output. However the pattern also seems to be attempting to apply the stereotype 'requirementUseCase' which does not affect the output. I do not know what that is trying to do.

Tested using player piano in Cameo Systems Modeler 19.0 SP4
Spreadsheet used as input to Ingrid attached
RelSys.xlsx

Player Piano breaks in 2021x-ownward due to API changes

changes to the Cameo/Magicdraw OpenAPI introduced in 2021x significantly break the way Player Piano handles the application of stereotypes (see 2021x News For Developers and Working with stereotypes and tagged values for information on the changes that seem to be impacting Player Piano)

The difference between the pre- and post-2021x APIs will require somehow handling the different versions of Cameo/Magicdraw if continued compatibility with pre-2021x is desired

Undefined variable in "replace" branch of Player Piano

The following line is in the "replace" branch of Player Piano:
type_to_get = com.nomagic.magicdraw.uml.ClassifierFinder.findClassifierOrDataType(live_project, 'String', [], sysml_package);

The variable sysml_package isn't defined anywhere. Based on the context, variable name, and method documentation, sysml_package should be set to the element that is the SysML profile package.

Looking at the findClassifierOrDataType() method documentation from 19.0 SP4 and later versions It doesn't look like this method has changed since at least that version. So any fix is probably independent of version changes

I'm not super familiar with what Player Piano is trying to do in this section, and I haven't yet encountered an error caused by this line. It would be worth having someone more familiar with RMT come up with a test case that actually makes use of this part of the script.

pattern "PropertyRedef" does not work

When running test data in Player Piano with the PropertyRedef pattern, all that is produced are two blocks and a generalization relationship. No properties are created (or redefined)

Tested using player piano in Cameo Systems Modeler 19.0 SP4
Spreadsheet used as input to Ingrid attached
PropertyRedef.xlsx

Unhandled exception in script

I've compiled the ingrid executable on my Windows machine per the instructions on the page. When running the EXE in the dist folder, I get the following error:

image

pattern "UCElements" does not work

When running test data in Player Piano with the UCElements pattern, stereotypes are not applied to classes. The stereotypes are not populated correctly in the output from Ingrid, which appears to be due to an issue with the pattern not specifying stereotypes with a list of dictionaries. The elements produced for the UseCase and Element portions of the pattern do not correspond to the element types that their names would intuitively imply. Additionally, there is no relationship between the Use Case produced and the Context Class (which should be a Block); no documentation is provided for the intent of the pattern, but this does not appear to be the intended result of using the pattern.

Tested using player piano in Cameo Systems Modeler 19.0 SP4
Spreadsheet used as input to Ingrid attached
UCElements.xlsx

None of the patterns that apply stereotypes are structured correctly (and should not be working at all)

Sometimes, but not always, running test data with some of the patterns will work
However, I don't understand how it is functioning at all at the moment.
I've yet to identify when it does or doesn't work.

None of the patterns currently contain (and so Ingrid cannot be producing) the information about stereotypes that Player Piano is currently written to ingest (a combination of ID for the profile and the name of the stereotype)

Based on what Player Piano is trying to do -- and on some of the comments in the script -- the stereotypes portion of all patterns should be:
"Vertex Stereotypes": { "<Name of Node N which has a stereotype to be applied>": [ { "profile": "<element ID of the profile containing the stereotype to be applied to Node N>", "stereotype": <stereotype to be applied to Node N> } ], "<Name of Node M which has no stereotypes to apply">: null }

However, I would consider always requiring the explicit ID of the profile to be a fairly annoying way to make patterns (since it makes them hard for a human to read). Calling out the profile by their human-readable name would be preferable. It should be pretty easy to implement a solution that can read in the name of a profile and identify the associated profile in the project. All of the patterns that currently call out a profile, do so by using the profile name. That would mean that the stereotypes portion of all patterns should be:
"Vertex Stereotypes": { "<Name of Node N which has a stereotype to be applied>": [ { "profile": "<name of the profile containing the stereotype to be applied to Node N>", "stereotype": <stereotype to be applied to Node N> } ], "<Name of Node M which has no stereotypes to apply">: null }
This form matches what is in the Composition pattern.

How stereotypes should be structured in patterns is not apparent in the pattern documentation. The closest thing is the image of the Composition pattern in rapid-modeling-tools/ingrid/src/model_processing/patterns/README.md, which does not match the actual contents of the Composition pattern. Additionally, The documentation mentions that only one stereotype can be applied, but that does not match what is actually implemented based on the comments on previous commits and actually looking at Player Piano, etc.

No published version of Pattern Builder

It has been a few years since the patterns readme added a section on Pattern Builder. Some development went into making a Pattern Builder model, but none of that has been published or documented within Rapid Modeling Tools

pattern "ActorContext" does not work

When running test data in Player Piano with the ActorContext pattern, the Block stereotype is not applied to classes. The stereotypes are not populated correctly in the output from Ingrid, which appears to be due to an issue with the pattern not specifying stereotypes with a list of dictionaries

Tested using player piano in Cameo Systems Modeler 19.0 SP4
Spreadsheet used as input to Ingrid attached
ActorContext.xlsx

Player Piano is full of untracked TODOS

The Player Piano script contains multiple "TODOS" as well as statements to the effect of "this will be fixed in the future." None of this is tracked anywhere. I think the comments in Player Piano need to be examined to determine if they contain actual issues that need to be tracked

Current patterns do not produce inputs that exercise all functions of Player Piano

While looking at making Player Piano compatible with 2021x-onward, I've found at least one instance of a now-depreciated API call in a section of Player Piano that isn't used when called on inputs produced by Ingrid for any of the included patterns. For the purpose of testing and of just demonstrating capabilities, I think it would be useful to expand the included set of patterns.

The area in question begins with:
if (value_shortcuts != null && attribute_to_hit == null){

pattern "UCOverview" does not work

When running test data in Player Piano with the UCOverview pattern, stereotypes are not applied to classes. The stereotypes are not populated correctly in the output from Ingrid, which appears to be due to an issue with the pattern not specifying stereotypes with a list of dictionaries.

Additionally, there is no relationship between the Use Case or the Actor produced and the Context Class (which should be a Block); no documentation is provided for the intent of the pattern, but this does not appear to be the intended result of using the pattern.

Tested using player piano in Cameo Systems Modeler 19.0 SP4
Spreadsheet used as input to Ingrid attached
UCOverview.xlsx

No Documentation of Version Compatibility/Version Support

There isn't any documented information on which versions of Magicdraw/Cameo are supported or are planned to be supported (or are not going to be supported).

It looks like RMT was originally developed with some version of Magicdraw/Cameo 18. There have been quite a few new releases in the ~5 years since then

pattern "SystemParts" does not add utility as implemented

Running test data through Player Piano with the SystemParts pattern produces elements with a modeling pattern identical to that produced by the Composition pattern (the underlying pattern files are identical)

Tested using player piano in Cameo Systems Modeler 19.0 SP4
Spreadsheet used as input to Ingrid attached
SystemParts.xlsx

Support for multiple metatypes

The way patterns are formatted and handled does not account for cases where there are elements with multiple metatypes. As an example of using multiple metatypes, the SysML stereotype TestCase has two: Behavior and Operation

Unable to launch player piano from Cameo Systems Modeler 2021x

ย  MagicDraw cannot execute the Groovy macro, please make sure that the C:\Users\yeole.paresh\rapid-modeling-tools\player-piano\player-piano-script.groovy is correct. startup failed: C:\Users\yeole.paresh\rapid-modeling-tools\player-piano\player-piano-script.groovy: 142: unable to resolve class JsonSlurper @ line 142, column 18. jsonSlurper = new JsonSlurper(); ^ 1 error org.codehaus.groovy.control.MultipleCompilationErrorsException

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.