AI Power Tools for Sparx EA Docs Release 3.6.4

Copy a package as new

Goal

Duplicate a package subtree, including its elements, attributes, operations, tagged values, connectors and diagrams, with fresh identifiers everywhere, so the copy is independent of the original. This is for an MDG author starting a new version, or an architect creating a to-be copy to work on. You end with a copy that matches the source in structure, with new identities, verified by counts and by identifier comparison, and an understanding of what was deliberately not copied.

Where it runs

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

Surface How it runs
Claude Code Fully
Claude Cowork Fully
Claude Desktop chat Fully, except the UI steps, which you perform: starting EA and opening the model, handling any dialog EA raises (you screenshot it, paste the screenshot into the conversation so the assistant can analyze it, then dismiss it), and comparing the source and copied diagrams in EA.
VS Code with GitHub Copilot Fully, except the UI steps, which you perform: starting EA and opening the model, handling any dialog EA raises (you screenshot it, paste the screenshot into the conversation so the assistant can analyze it, then dismiss it), and comparing the source and copied diagrams in EA.

How it works

EA's own interface has a "Paste as New" command. The server works through EA's automation interface, which has no matching call, so duplicate_package (Packages) recreates the subtree object by object, which is what gives every copy new identifiers. With computer use the assistant could instead operate the command in EA's window, but this scenario describes and verifies the AI Power Tools operation. By default the copy lands beside the source, under the same parent, with the same name. You can give it a new name and place it under a different parent.

What is copied:

  • Packages (the full subtree), elements, attributes, operations (with their parameters) and element tagged values, with names, types, stereotypes and a fixed set of properties.
  • Internal connectors (both ends inside the subtree), with both ends remapped to the new copies.
  • Crossing connectors (one end inside, one outside), with the inside end remapped. The outside end still points at the original external element, which is never duplicated. The copy therefore stays linked to things outside the subtree.
  • Diagrams, with their objects (geometry and sequence preserved, element references remapped when the element was copied) and stored diagram links. A composite diagram's owning element is remapped when the owner was copied. Check on your first copy that diagram counts match, which step 4 does anyway.

What is not copied: classifier references (an attribute typed as another class is left unset on the copy, and the result lists these as not duplicated), and diagram links whose connector was not duplicated (counted as skipped). Connector properties copied are the notes and direction. Anything else, for example constraints, requirements, scenarios or linked documents, may not be copied; check it in the copy before relying on it.

Before you start

  • EA is running with the right model open. The copy adds content and changes nothing in the source, but a baseline of the parent package is cheap if you plan follow-on edits there.
  • You know the source package and, if you want the copy elsewhere, the target parent.
  • Source counts to compare against (step 2).

Steps

  1. AI with computer use; otherwise you If EA is not running or the model is not open, start EA and open it. AI Power Tools ea-start-here runs the preflight, and ea-modeling reads the source package and its tree. You confirm source, name and placement.
  2. AI Power Tools ea-modeling records source counts: elements, connectors, diagrams and diagram objects.
  3. AI Power Tools ea-modeling duplicates the package, asking for the old-to-new identifier maps so the copy can be verified.
  4. AI Power Tools ea-modeling compares the counts in the result with the source counts.
  5. AI Power Tools ea-modeling proves the identifiers are fresh and that the copy does not point back into the source.
  6. AI ea-modeling checks what was not copied and examines the crossing connectors. You decide whether the copy is fit for purpose.
  7. AI Power Tools ea-diagram-composition renders the source and the copied diagrams. AI with computer use; otherwise you compare them visually, in EA's window where that helps.
  8. AI Power Tools ea-modeling renames or relocates the copy if needed.

Step 2, source counts. The assistant counts elements and connectors in the subtree and notes the number of diagrams and diagram objects. The package tree with element counts gives the per-package figures (Packages).

Step 3, the result. A successful copy reports the new package, the counts copied (packages, elements, attributes, operations, parameters, tagged values, internal and crossing connectors, diagrams, diagram objects, diagram links and skipped diagram links) and what was not duplicated. Asking for the identifier maps is what makes verification possible. A missing source or target parent is reported as not found.

Step 4. The counts should equal the source counts: elements for elements, internal plus crossing connectors for the connectors that touched the subtree, diagrams for diagrams. A difference needs an explanation before the copy is used. Crossing connectors above zero is expected when elements connect to things outside the package; those new connectors point at original external elements.

Step 5. Two checks. First, identifiers: no identifier in the new subtree may appear in the source. Second, no leakage back: every new connector's endpoints must resolve either to a copied element or to something that was never in the source subtree. A connector in the copy that still ends on a source element is a defect.

Step 7. Placed elements keep their geometry, and connector links are remapped. Differences usually mean an element the diagram shows lives outside the copied subtree and still points at the original.

Prompts to use

Opening:

Follow-ups:

  • Verify: "Prove the identifiers are all new, and list any connector in the copy that still ends on an element in the original."
  • Crossing: "Which connectors cross the package boundary? Those still point at the originals, right?"
  • Not copied: "What didn't get copied? Check attribute types that reference other classes."
  • Compare: "Render the primary diagram from both and tell me if they differ."
Model Fit Why
Claude Fable 5.1 Capable The copy is deterministic; judgment is limited to deciding the copy is fit for purpose
Claude Opus 5.5 Capable Same
Claude Sonnet 5.5 Recommended Procedural verification with counts and comparisons
Claude Haiku 4.5 Capable Fine for the copy and the count comparison; supervise the leakage check

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

Checking the result

  • Correct. The new package's identifier differs from the source's. No identifier in the new subtree appears in the source subtree. Names, stereotypes and tagged values match on a sample of elements. Every new connector has the same type and stereotype as its original. Red flag: a copied connector that ends on a source element.
  • Complete. Counts equal the source's, element for element and diagram for diagram. Skipped diagram links are zero unless you asked for no connectors. The list of what was not duplicated shows only what you expect. Red flag: a diagram count that is lower than the source's.
  • Nothing unintended changed. The source package's element, connector and diagram counts are the same after the copy as before it. No connector in the source gained or lost an end.

Variations

  • A new MDG version. Duplicate the source model's profile package, then rename it (for example with a version marker) and record the new package and toolbox-diagram identifiers. The profile ids in the built MDG derive from them. See ea-mdg-model-build (ea-mdg-model-build) and the modeling-language scenarios in Governance.
  • A to-be copy for a planning exercise: duplicate, then work only in the copy. Crossing connectors still point at current-state elements, which is usually what you want.
  • No connectors or no diagrams. Choosing no connectors skips all connector duplication (diagram links then cannot be copied); choosing no diagrams skips diagrams, their objects and their links.
  • Across repositories. Duplication works inside one repository. To move a package between repositories use XMI export and import (Move content in and out of Enterprise Architect). For a profile package, ea-mdg-model-build advises against XMI, because two packages claiming the same profile id is worse than a manual copy.

Limitations

  • Classifier references are not remapped. An attribute typed as another class is left unset on the copy, even when that class is in the same subtree. Profile mechanics attributes (tagged-value definitions and the like) are untyped in normal use and unaffected.
  • Crossing connectors point at originals. That is deliberate. If you want a fully self-contained copy, delete or retarget them.
  • The copy has the same name by default. Both trees show a same-named sibling. Give it a new name or rename it right away.
  • It is slow on large subtrees, because it works object by object. If a call seems to hang, check EA for a dialog box. With computer use, the assistant sees the dialog in EA's window, reads it, uses the message to correct the call, dismisses the dialog and keeps going. Without computer use, you take a screenshot of the dialog and paste it into the conversation so the assistant can analyze it, then you dismiss the dialog so processing can continue.
  • A write EA rejects can be reported as success. Verify with counts, not with the confirmation.
  • Moving a subtree is a copy followed by deleting the original, a direct change to the package's parent in the repository, or a move in EA's own Browser window (a UI step, which the assistant performs with computer use and otherwise you do); each carries risk, so baseline first.