Modeling languages
In this section
| Page | What it covers | Code | Cowork | Desktop chat | VS Code |
|---|---|---|---|---|---|
| ea-mdg-assess | Find out which modeling-language situation a repository is in, before anyone authors or builds a technology. | Yes | No | No | With you |
| ea-mdg-author | Write a modeling language directly as MDG Technology XML: stereotypes, tagged values, diagram types and toolbox pages. | Yes | No | No | With you |
| ea-mdg-model-build | Build a versioned MDG Technology from a source model held in the repository. | Yes | Partly | Partly | With you |
| ea-mdg-deploy | Put a built MDG Technology into a model or onto a machine, and prove that it works. | Yes | Partly | Partly | With you |
Where it runs: Yes = runs fully · With you = runs, and you do the steps in EA’s window · Partly = one part needs a capability the client lacks · No = not available · TBC = to be confirmed
In Sparx EA a modeling language is an MDG Technology: a set of stereotypes applied to base element types, the tagged values those stereotypes carry, optional custom diagram types and toolbox pages, optional Quick Linker rules (the hover menu that creates connectors), and optional reference data (the closed lists behind dropdown tags). Four skills cover the life of one:
| Skill | Question it answers | Logic |
|---|---|---|
ea-mdg-assess |
What language situation is this repository in, and what state is a given technology really in? | AI + AI Power Tools checks |
ea-mdg-author |
Write the technology directly, as a file. | AI + AI Power Tools checks |
ea-mdg-model-build |
Build the technology from a source model held in the repository. | AI + AI Power Tools checks |
ea-mdg-deploy |
Put a built technology into EA and prove it works. | AI + AI Power Tools checks |
Three ways to get a technology
There are three ways to arrive at an MDG Technology. They differ in where the definition lives, and that decides who can change it safely.
| Way | Where the definition lives | Skill that does the work | Fits when |
|---|---|---|---|
| Hand-authored | The technology file itself is the source of truth | ea-mdg-author |
A one-off or small technology, a patch to an existing file, or no repository to host a source model |
| Built from a source model | Profile packages inside a repository; EA exports them into the technology file | ea-mdg-model-build |
The technology has a lifecycle: several versions, more than one author, a metamodel that stakeholders review |
| Generated from current usage | A census of the stereotypes people already use becomes a candidate metamodel, which then continues as a hand-authored file or as a source model | ea-mdg-assess to census and decide, then ea-mdg-author or ea-mdg-model-build |
The repository already contains an undeclared language and you want to formalize it |
A hand-authored file and a source model diverge permanently. If someone hand-edits the file of a technology that has a source model, the next export from the model silently discards the edit, with no warning and no record. Pick one approach per technology and record the choice in the technology's own notes. A technology can move from a hand-authored file to a source model (import the file into the repository as a profile package, then never hand-edit again), not the other way round without losing the source model.
Where a technology is installed
Manage Technologies shows a Location for every technology. An installed technology sits in one of three places, and the place decides who gets it and what it keeps:
| Location | How a technology gets there | Who gets it | What it keeps |
|---|---|---|---|
| Model | Import to Model in EA's Import MDG Technology dialog; Import Package as MDG Technology; or install_mdg with the model scope, built from a package stereotyped as an MDG technology |
Everyone who opens the model | The whole technology, toolbox pages included |
| Project | EA's technology import call, which Sparx documents as the route from before EA 7.0; or install_mdg with the embedded scope |
Everyone who opens the model | Profiles and diagram types. No toolbox pages: EA offers one automatic page built from the stereotypes |
| A file name | A technology file in a folder EA loads technologies from: the per-user technologies folder or a configured search path; or install_mdg with the user scope |
That workstation only | Everything |
Location: Model is the one to prefer. Location: Project suits a technology that has no toolbox pages. Keep one technology id in one place. When the model holds the same id at both in-model Locations, EA lists both and answers the version from the Project copy; a workstation file for an id the model also holds shows as a duplicate entry with an asterisk.
Where assess and deploy fit
ea-mdg-assess is the entry to all three ways. It tells you whether a technology exists, where the model stores it, whether it is loaded and enabled, whether it has a source model, and how well the repository's stereotype usage conforms to it. Its answer decides which authoring skill comes next. ea-mdg-deploy is the exit of all three: whichever way the file was produced, deployment stores it in the model or installs it for the workstation, proves it is loaded and enabled, and retires old builds. After a deploy you can run ea-mdg-assess again to confirm the repository's situation is as intended.
All examples in this section use Westbrook Bank (technology WBA, display name WestbrookBankArchitecture, qualified stereotype WBA::WBABusinessApplication; model WestbrookBank.qea) as an illustration. Replace them with your own technology, stereotypes and model; nothing here assumes you have the Westbrook model.