Build an MDG Technology from a source model

Goal

Build a technology from profile packages that live in the repository, through to the XML file, a version stamp and a verified deployment. For an MDG author. You end with a built technology whose stereotypes, tags and profile ids match the source model, stamped with a version, read back, deployed and confirmed loaded.

Where it runs

This scenario needs the MCP server. Computer use covers its UI steps.

Before you start

• The start-of-session check and Assess the language situation, with the path recorded.
• A source model, or a first version to create (Generate an MDG Technology from current usage).
• EA 17.1 or later for Save Package as MDG Technology. On earlier versions the command is absent, not greyed out, and the alternative is the MTS Generation Wizard, which needs a file that only the wizard can produce.
• A package with the stereotype «mdg technology». Name it for the id you want, in 12 characters or fewer. The technology id comes from the package name, and a longer name has been seen cut to 12 characters on one route (WBA Technology became WBA Technolo) and kept whole on another.
• Computer use for the Save step, or a person at EA.
• A baseline of the source packages, and the protections in step 2. One later step is irreversible and leaves no error.

When a technology has a lifecycle (versions, several authors, a metamodel stakeholders review), its source of truth is a model in the repository: profile packages, a toolbox profile and a diagram profile. EA generates the technology file from them. ea-mdg-model-build drives the model work through AI Power Tools and the build through EA's interface.

Steps

1. AI with computer use; otherwise you If EA is not running or the model is not open, start EA and open it, and check Manage Technologies in EA's window. AI Power Tools ea-mdg-model-build and ea-mdg-assess confirm that the current technology is imported and enabled (the runtime reading).
2. You Protect the baseline, and confirm the archive before reference data is touched. Tagged value types live in a repository-wide table. The moment a new-version type is added, any export from the old profile packages stops being the old version, silently. So: re-export the current profiles (publish_package_as_profile) and account for every difference against the deployed file; archive every artifact (profile files, the wizard file, the built technology) into a package; take a baseline of the source packages (create_baseline); and rename the baseline roots unmistakably, for example [1.1.0 BASELINE - DO NOT EDIT]. Renaming is the cheapest protection and, unlike locking, blocks nobody.
3. AI Power Tools ea-mdg-model-build creates or duplicates the package structure (duplicate_package, create_package). A duplicate generates fresh identities throughout, like Paste as New. A duplicated profile package has the same name as its source, so both trees show a child called WBA. XMI export and import is not a substitute: it does not dependably strip identities, and two packages claiming the same profile id is worse than a manual copy. Check the copy at once against the source, including diagram counts. Record the new package GUIDs and the toolbox diagram GUIDs, because the profile ids in the built file derive from them.
4. You Approve the metamodel changes, then ea-mdg-model-build edits the profile: stereotypes, tags, Extension links and constraints.
5. You Settle reference data. Check what already exists before authoring a type: a type may already be defined and simply never selected into a build, so a tag behaving as free text does not prove it is missing. Treat an inferred enumeration domain as a candidate, never the answer. Where the repository already carries the technology, the runtime reading returns its complete declared domains.
6. AI Power Tools ea-mdg-model-build builds the toolbox and diagram profiles.
7. AI Power Tools ea-mdg-model-build exports the profiles (publish_package_as_profile). Always pass a version. EA reads a package's version only the first time that package is published in a session and then caches it, so a republish silently emits the old value. The response reports the version EA held beside the version written.
8. You Approve the build step. AI with computer use; otherwise you ea-mdg-model-build with ea-help runs it: select the «mdg technology» package in the Browser, choose Specialize, Publish Technology, Save Package as MDG Technology, choose a path in the Save As dialog, and EA reports MDG Technology successfully saved to file. Read System Output, not just the dialog. It carries diagnostics the dialog omits, such as WARNING: Duplicate profile name. A build can report success and still have collided. Do not confuse this command with Import Package as MDG Technology, on the same menu. Save writes a file and installs nothing. Import builds the same technology and imports it into the open model at Location: Model, toolbox pages included, and writes no file.
9. AI Power Tools ea-mdg-model-build stamps the version. Generated files come out with an empty version attribute, and setting the package Version beforehand does not carry through. Two unversioned builds are indistinguishable in Manage Technologies. Stamp the version in the file's documentation element, and state it in the technology's description too, so you can tell builds apart.
10. AI Power Tools ea-mdg-model-build and ea-validation read the built file back and compare it with the source. The check that catches the expensive mistake: the profile ids in the file must match the packages and toolbox diagrams of the new version, not the previous one. A correctly versioned file built from the wrong source passes every other check. Then: every new stereotype has its extension target populated (an empty one means a missing Extension), every constraint is namespace-qualified, removed stereotypes are absent, new tag types are in the reference data, and all profiles carry the version. Match on exact strings and never prefixes: profiles routinely carry near-identical names whose blast radius differs a great deal. A validation rule (tagged_value_type_shipped) flags a type that is defined in the profile and not shipped in the built file.
11. You Deploy and prove it, as in Deploy an MDG Technology and prove it works.

Source model mechanics. These are conventions, not an EA feature you can look up.

The package structure is a technology package holding a design metamodel (an ArchiMate view, human-readable) and a profile package. The profile package holds three children, and the stereotype of each child routes its content to a section of the built file.

Stereotyping all three «profile» piles everything into the UML profile section and leaves the other two empty.

A stereotype with no Extension never exports. It sits in the profile package looking complete and appears in no technology. Generalization does not do the job of Extension. On EA 17.1, builds made with Generalization came out with every stereotype extending nothing, and converting each connector to Extension produced a correct result for each. If the server declines to create an Extension link, draw it in EA's interface, a UI step that is AI with computer use; otherwise you. Namespace-qualify every constraint value (WBA::WBABusinessApplication): an unqualified one fails silently, and with enforcement set to profile, enforcement is then live against a rule that cannot resolve. Connector tagged values are written with their own operation (set_connector_tagged_value): updating the connector ignores a tag passed as a property.

Toolbox pages are elements on a toolbox diagram. Each palette item is an attribute on the page element: its name is <Tech>::<Stereotype>(UML::<Metaclass>), its default is the label shown, and its type is blank. Removing a stereotype leaves its toolbox entry behind, so sweep the toolbox after every removal. A stereotype on no toolbox page ships invisible. The UML profile exports from the «profile» package, and the diagram profile from the «diagram profile» package. Each toolbox exports from its diagram, through EA's automation interface or on the screen, where the command is greyed out unless the diagram is open.

Prompts to use

Opening

Follow-ups

Recommended models

Ratings are guidance based on the kind of reasoning the skill needs, not measured benchmarks.

Checking the result

• Accurate. The built file's profile ids match the new source packages. Its stereotypes, extension targets and tags equal the source. Every constraint is qualified, and the version is stamped. After deployment, the runtime reading reports a live source, the Location you installed to, and the new version.
• Complete. The file has the sections the source implies (UML profile, diagram profile, toolboxes). Every stereotype is on a toolbox page. Every tag whose type should be a dropdown is one. Nothing the plan removed remains.
• Nothing unintended changed. Baseline packages are unchanged. Comparing the source with its baseline shows only the intended edits. Exactly one entry for the technology id appears in Manage Technologies, at the new version and the Location you intended.

Variations

• First version generated from a census. There is nothing to duplicate. See Generate an MDG Technology from current usage.
• EA before 17.1. Use the MTS Generation Wizard. The wizard file cannot be hand-written because its schema is not published. Run the wizard once, keep the file under version control, and edit that file from then on. Its Tagged Value Types page is a selection step: a type not selected does not ship, however fully it is defined.
• Bring a hand-authored technology under model control. Import the XML as a profile package first (Publish Technology, Import Package as UML Profile), then never hand-edit again.
• Importing a new version over an older embedded build. Importing over an old build has been reported to leave the old profile loaded. Retire old builds by disabling them in Manage Technologies (Deploy an MDG Technology and prove it works).
• Install straight from the package. Skip the file and install at Location: Model from the «mdg technology» package (Deploy an MDG Technology and prove it works). You then have no file to read back or ship, and the version the installed copy declares is whatever the build carried, so read it back.

Limitations

• Saving the technology to a file is done in EA's user interface. The AI performs it with computer use; otherwise you do. Installing from the package into the model is an operation.
• Generated files carry an empty version. Stamp it. A technology that declares no version reports none, not a default.
• Tagged value types and reference data may not ship. A built file can carry no tagged value types or reference data. If your tags must ship as dropdowns, check that explicitly with the validation rule in step 10.
• The save command must exist on your EA build. Check that the menu item is there.
• Trap summary. A stereotype missing from the file: no Extension. A toolbox entry that points at nothing: the stereotype was deleted and the toolbox not swept. A tag that stays free text: not selected into the build. A Quick Linker rule that never fires: an unqualified constraint. Only the author sees the new version: a registration from a file on disk is shadowing the model copy. Everyone sees an old version: a Project copy of the same id is shadowing the Model copy. The export is the previous version's content: the wizard file references old filenames.
• Ask before running any direct query that writes against a live repository. The direct-query operation of AI Power Tools accepts writes.