Why Blueprint?
You already have
a Big MBSE Tool
(with Big Tool problems)
Let’s fix that
Blueprint is not a Big Tool
It’s an open source MBSE tool chain
Models are human readable text
So it’s AI friendly
There’s no clunky model editor
So you can use your favorite IDE
And your own configuration management
Swap or modify any module in the tool chain
Works with any MBSE standards
No license keys
And, you can still use it with that Big Tool you have
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 (or us directly) to get it done.
The path from requirements to running code is open source, but optional proprietary components can be developed, typically with the help of AI, 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. This also includes the possibility of integrating with existing MBSE tooling.