Why Blueprint?
As modelers, our tools should match and exceed the rich feature sets of modern software IDEs.
Monolithic modeling tools have never evolved fast enough and delivered the quality and productivity we expect as requirements and systems engineers.
We propose a different set of principles to get us on the right trajectory.
Define and maintain the models as human readable text
It’s not enough to quickly slap a model together. You need to maintain it. Change it. Sometimes drastically. Who has time to straight all those lines and push those boxes around so that they remain readable? Nobody, so your only choice is to leave the diagram a mess as you plow forward or rely some sort of automatic layout that outputs a bird’s nest.
Even with the best graphical editors, it’s a slog when it comes to model development on large complex projects. Developers work faster with text.
Keep semantics separate from graphical layout
The key to maintaining models in text is to filter out the graphical information as a separate layout sheet, as we do with the Flatland app. Now you can diff your models, put them under configuration management, and enjoy all the features of your favorite editor and IDE.
Use your own favorite IDE
The first two principles set the stage for using your own development tools. Since you are editing text, you can take full advantage of features that you know and love like syntax coloring, autofill, folding, comment blocking, etc. If you like Eclipse, use Eclipse. Pycharm? Sure. VIM, why not?
One metamodel, many small modeling apps
To prevent complete chaos, we establish a single metamodel for our variant of Executable UML. It defines our modeling language and the shape of our repository. Beyond that, any app is free to insert itself anywhere in the tool chain. The idea is to keep the modeling apps small, focused, and easily combinable, much like *nix tools.
Rely on the community for new features, not a single vendor
So instead of waiting around for your vendor to supply a much needed feature, you can add it yourself or work with the community to get it done.
The path from requirements to running code is open source, but optional proprietary components are welcome to speed the journey
There’s nothing to prevent someone from creating a proprietary UX experience that updates the human readable model text, model repository, or any other chunk of data in the pipeline. In fact, this sort of thing is quite welcome. This also includes the possibility of integrating with existing MBSE tooling.