Federated modeling

I (=Meinte) have several projects which would benefit from a modeling environment, but for which it’s unrealistic to try and set up any kind of central repository. This has various reasons: in one situation (EU DCC / eHN), modeling takes place in wildly-differing organizations in separate countries under heavy restrictions (such as: no network access), while in another situation it’s politically undesirable to install tooling and inject additional steps into an existing deployment pipeline.

In such contexts, an offline modeling environment running in the browser would be beneficial. It can be run locally, without needing to install anything, just by transporting a ZIP with the modeling environment as a HTML file. There’d be no connection to a repository - instead, users perform explicit loads from, and saves to files. Typically, imports from and exports to existing, non-model-like artifacts also play a role. The drawback of this situation is that there’s not much control over which version of the modeling environment users happen to have.

Such a modeling environment would benefit from LionWeb in the following ways:

  • It provides a stable basis for the serialization of models.

  • That serialization would be pretty robust against format changes because of the built-in fault tolerance and resilience.

  • Using LionWeb standards and protocols would be politically more palatable than some bespoke, ad-hoc format.

  • The reference architecture applies just as well to a “fat client”-style Web app (ran from a local file).

Code bases analysis and migration

In some situations we may need to process large codebases with tens of thousands of files and tens of millions of lines. In this situations it would be convenient to have a model repository where to upload the single ASTs obtained parsing single files and then perform symbol resolution across files. We may also imagining having symbol resolution being re-performed as files are changes. Once the ASTs are stored in the model repository we could calculate statistics, navigate the code, generate diagrams, etc. We could also perform model transformation as part of language migrations.

In this situation we would benefit from LionWeb because:

  • We could store the ASTs and not have to parse all the files and keep them in memory to perform symbol resolution

  • We could have parsers, symbol resolvers, language migrators, and code generators written in different languages and coordinate through the model repository. LionWeb would provide the lingua franca for interoperability

Connecting new and existing (web) apps

In brownfield scenarios, several tools that implement editors for certain (more precise or less precise) modeling or specification purposes already exist. If one doesn’t want to redevelop each of these tools, there needs to be a way to connect such (let’s call them) legacy tools. Connections can be relatively simple connections, where a LionWeb repository component could be treated as a simple database that the tool can connect to in order to exchange information in a simple way ("model-bus scenario"), just dumping or retrieving data. More complicated (and way more interesting) scenarios would be ones where we can talk about (various forms of) semantic interoperability. (How) should LionWeb help with such interoperability? Let’s have a look at some examples to give a bit more body to this use case.

Multi-domain co-specification (e.g. game development)

Imagine there are various homogeneous off-the-shelf tools (to stay in the game development example: game engines, 3D modeling, motion capture, sculpting, etc.) and various in-house tools (e.g. dialog editor, level editor, asset editor, builds editor, scripting, etc.). At least some of the tools would benefit from cross-connections over various types of tools. Some in-house tools may be new for a project, so we can use nice language technologies. Some other in-house tools may be adapted, but not completely rewritten, so we could sprinkle some connections to a LionWeb repository in-between the existing implementation. At least some of the off-the-shelf tools could be suitable for connection (and it would be desired to connect them), e.g. some of the game engine editors should interoperate on a level of specification semantics with a dialog editor, so that certain events in the game can be associated with a piece of storyline or dialog.

System(s) of systems (e.g. hospital or smart city) development and maintenance

Let’s take the example of a smart city. There will be several systems that need to be configured and require subject matter experts to do so. For example, the procedures for an emergency (fire department or ambulances) alarm center and in-the-field personnel may need to interoperate with the power grid or with traffic regulation. The difference of this scenario with the multi-domain co-specification would be that models may be not only on a specification-level but (at least parts of the models) may be running live in an in-production system (like traffic control) or a combination of systems (like negotiation between an ambulance and traffic control). LionWeb may also help with the aspect of running models in-production and/or let such in-production artifacts interoperate with (offline) specification artifacts needed to develop and configure the various systems.

Multi-disciplinary, multi-tool-bridge systems development/engineering

Typically, high-tech machines (like cars, airplanes, electronics production, high-end printing, etc.) have a complex multi-disciplinary development process with non-trivial integrations on various levels. Specifications from various disciplines (mechanics, electronics, software, material science, etc.) will have many interactions. Here, all kinds of scenarios as mentioned in the multi-domain co-specification example are possible (cross-mappings between disciplines on various levels, vertical and horizontal integrations, as well as system-level to various other discipline-levels and possibly vice versa). When taking into account implementation of such a system, even scenarios from the system(s) of system example are possible (e.g. use of a model in production in a working system - yes you could use code generation as well, but there is a whole different level of reuse and integration if you are not always forced to "generate the actual semantics of a model away").

In addition to the earlier cases, there are various development exploration scenarios (it may be that some of these can be mapped to earlier described examples in general, but it’s not sure how and to what level):

  • Simulate a (possibly multi-disciplinary) piece of a product specification for purposes of understanding impact of design choices.

  • Explore or optimize a system design (which may involve several domain/product-specific models and several off-the-shelf models having to interoperate in order to reach over and effectively explore a multi-disciplinary design space).

  • Apply measurements and logging in order to gather data from the real world or systems in development or in the field for validation of models or for syncing up models better with reality.

  • Generative design: this involves ML models (like stable diffusion or GPT) to interoperate on some level with the various other domains (be it specific in-house or off-the-shelf).

LionWeb technology can help there with various concepts:

  • Enable easier to access web-based editors for various specification needs, while not having a completely random ecosystem of tools (but rather allowing for deeply (semantically?) integrated DSL ecosystems)

  • Allow for hiding of complexity by enabling separation of concerns for various users of the total system.

  • Allow for declarative development of DSLs and then deployment into various forms (e.g. editor into MPS or as a parser or web-based, but on the same, or at least partially the same, declarative specification; processor as a service either native or on a server; etc.).

  • Make processors scalable (could be a simple client-based processor or a very complex computation on server-side, all the way from checking big state spaces to complex computational co-simulations).

The above things could also be done by a single technology like MPS for web or Modelix, however LionWeb can help to componentize and choose different components or implementations from different parties/vendors in order to:

  • Select best-of-breed for a specific need

  • Spread the risk of certain components by allowing for exchanging (up to a certain level) one component by an equivalent component that is good enough to meet the needs.

Some more detailed sub-use cases would be:

  • A web-based textual/HTML-like editor for an MPS language running from a web server

  • A web-based diagrammatic editor similar to de.itemis.editor.diagram (useful for building and prototyping standardized diagrams)

  • A python-based (or Visual Basic-based) plugin in an off-the-shelf tool (desktop application) that needs exchange information (some graph of nodes) with a LionWeb model repository

  • A custom web application (e.g. 3D visualization/animation of some aspect of a system) that needs to exchange (soft-)realtime information with a LionWeb model repository

  • Several (possibly big amounts of) models with dependencies between them (with several different languages behind them - a language stack/ecosystem) are editable and run in a web-based fashion (e.g. in-client, served from some web server) - "megamodels"?

  • One or more server-based processors (e.g. MPS with typesystem and constraint checks, etc.) interact with a web-based editor as a client in a web browser

  • Resources and authorization: shield off certain internal information in a model and only expose derived values/attributes/behavior due to secrecy (e.g. secret company information, sharing of models with suppliers that can’t have access to all information, etc.).

  • A mixed situation of pure-web editor (e.g. some specialistic diagramming tool) and a "LionWeb-enabled/connected editor", e.g. embedding of textual things (KernelF expressions?) in the pure-web diagrammatic editor.

  • Storage of bigger models (like simulation results with possibly lots of data that needs to be related to manually written specifications) -→ would a LionWeb repository support this, or would it be useful to have a kind of "git Large File Storage" connection to another repository (like a binary repository, e.g. Maven or some more dedicated data store repository)? Or would that completely fall out of the scope of LionWeb?

Rapid language prototyping / deployment with async user feedback

When developing new languages, we might separate a few phases:

  1. Core build-up in direct cooperation with domain experts

  2. Refinement with larger group of experts, less direct interaction

  3. Roll-out

LionWeb would be useful for phase one, and especially helpful for phase two.

Phase one could be done with MPS, deployment is not much of an issue, as there’s close collaboration and language engineers can help out. Whatever is done in this phase benefits from LionWeb compatibility so that we can move smoothly to phase two.

LionWeb shines in phase two: It provides the plumbing for web-based deployment, and possibly more:

  • default implementations for different clients (repository, generic web editor, interpretation engine, model checking engine, …​)

  • language evolution facilities

  • versioning/collaboration

  • …​

Implementing any of them independently would be infeasible, so the alternative would be shipping 2 GB fat clients to all users every week. This would not inspire high involvement, so LionWeb enables more and faster feedback.

Technical (not very helpful) use-cases

MPS Backend

Access all modules (ie. languages / solutions / generators / devkits), models, nodes, properties and links present in an MPS repository when using an MPS-based backend. No access control, i.e. everything is readable and writable.

MPS Client

Access all models provided by the connected backend. In a first version, we can assume the languages are already present in MPS, i.e. we only read/write M1 models.

EMF Backend

Retrieve/store repo contents from a bunch of .ecore / .genmodel / .xmi files. No access control.

EMF Client

Access repo contents as EClass / EFeature / EEnum / EObject / etc. No access control.

Web Display

Access all (M1) models provided by the connected backend read-only from a web server written in Java. Access all (M1/2) models read/write from a different client.

Web Editing

Read and write access to all M1 models provided by the connected backend.

File Backed for Testing

Complete contents of repo are read from a file. By a configuration flag, it’s read-only or read/write; in the latter case writes are only in-memory (i.e. not persisted).

Services

Services or components which access all/parts of the model to compute specific derived knowledge (e.g. typesystem, scopes, BI or pre-computing/analysis for web displays).

Generator-out

Generator takes (big part of) the model, turns it into some output outside the model (e.g. text).

Model-to-Model Transformation

Mapper takes part of model and writes/replaces other part of the model.

Non-use cases

  • Store other things than models, e.g. images, (binary files), etc.

  • Custom persistence (automatic parsing or unparsing)