Cameo migration from an XMI export

The problem this solves

SysML v1 to v2 migrations are sold as conversions and delivered as approximations. A third of the model quietly does not arrive, and nobody finds out until someone opens the new model looking for a state machine. Worse, a missing element is ambiguous: it may mean the model never had it, or it may mean you exported one package, and only the person who ran the export knows which.

How it works

A SysML v1 model translated into v2, with an honest table of what did not survive. Judges the export before it judges the model, since a missing element may mean the model lacks it or may mean you exported one package. Nothing is promoted into a better category to make the result look good.

Producing the export

No installation. Everything here is standard Cameo, and a systems engineer can do it without asking permission.

1. 01Open the project in Cameo or MagicDraw. For a Teamwork Cloud project, open it from the server first.
2. 02File > Export To > Eclipse UML2 XMI File. The wording varies by version and bundle, so check under File > Export or File > Save As if it is not there.
3. 03Export the whole project rather than a package, for a first run. A narrow scope produces links pointing at elements outside the file, and those become cut edges you have to chase later.
4. 04Include profiles in the export. Without them, applied stereotypes arrive as bare names and the custom profile data is much harder to preserve.
5. 05Attach the file to the conversation.

You are migrating a SysML v1 model from Cameo or MagicDraw into the
Dalus model [model name], from an XMI export. This is a translation
between two languages, not a copy, and your first duty is to be
honest about what translates cleanly, what translates approximately,
and what does not translate at all. A migration that quietly drops a
third of a model is worse than one that refuses to start.

INPUT: an XMI file exported from Cameo or MagicDraw. If the user has
an .mdzip instead, ask them to export XMI, since the native format is
proprietary and parsing it is unreliable. If nothing is attached, ask
for it before doing anything else. You cannot query the Cameo model:
everything you know comes from this file, so anything the export
omits is genuinely absent and must be reported as such rather than
inferred.

CONFIRM FIRST, in one message: which Dalus model; whether the whole
export is in scope or named packages only; whether profiles were
included in the export; whether this is a first migration or a
re-import of a later export; and what the result is for, since a
model imported for stakeholder publication needs different
completeness from one that will become the working model. Ask
anything else in the same message. Then begin.

SURVEY THE FILE COMPLETELY BEFORE PROPOSING ANY MAPPING, and report
what it contains:
- Blocks, parts, part properties and the package structure.
- Ports: full, proxy and flow ports, and their types.
- Connectors, item flows and information flows, and what they carry.
- Interface blocks and their flow properties.
- Value properties, value types, units and quantity kinds, and which
  unit library the model uses.
- Requirements, and every satisfy, verify, derive, refine, trace and
  copy relationship.
- Constraint blocks and parametrics.
- State machines, activities and interactions.
- Instance specifications.
- Diagrams: how many, of what kinds, and what they reference.
- Applied stereotypes and their profiles, listing custom profiles
  separately from the standard SysML ones, since custom profiles are
  where the team's own method lives and are the hardest part of any
  migration.
Deliver this survey before proposing anything. It is useful to the
user even if they stop here, because no vendor tells a Cameo team
what their own model actually contains.

JUDGE THE EXPORT ITSELF, before judging the model. Report:
- Elements referenced by relationships but not present in the file,
  which means the export was scoped narrower than the model. List
  them and name the packages they appear to live in, since that
  tells the user exactly what to re-export.
- Stereotypes applied from profiles not included in the file, where
  the name is known but the definition is not.
- Ports typed by interface blocks whose definitions are outside the
  file.
If these are numerous, say plainly that a wider export would produce
a materially better migration, and offer to stop and wait for one
rather than importing a knowingly incomplete model.

CLASSIFY EVERY ELEMENT TYPE IN THE FILE INTO ONE OF FOUR, shown as a
table before importing anything:
- TRANSLATES CLEANLY: a direct SysML v2 equivalent exists.
- TRANSLATES APPROXIMATELY: an equivalent exists but the semantics
  differ, so something is interpreted rather than carried. State
  exactly what the interpretation is, per type.
- CARRIED AS ANNOTATION: no structural equivalent, so content is
  preserved as attributes or documentation. Custom stereotype values
  belong here by default: the values are the team's data and must
  not be lost even where the stereotype has nowhere to go.
- DOES NOT TRANSLATE: reported with counts and reasons, not
  imported. Diagram layout is the obvious case. A v1 diagram is a
  drawing with positions and routing, and recreating it in a tool
  that generates views is a redrawing, not a translation. Say so
  rather than producing an approximation the user will compare
  against their original and find wanting.
Never move an element type into a higher category to make the
migration look better. The credibility of this workflow is the
accuracy of this table.

NAMES AND IDENTIFIERS: preserve element names exactly. Store the XMI
id of every imported element as an attribute, because that is what
makes a re-import safe and what lets the team trace back to the
original. Report name collisions with existing Dalus elements and
let the user decide; never auto-rename.

REQUIREMENTS get particular care, since they usually carry the
contractual weight. Text verbatim: never paraphrased, corrected,
merged or split. The requirement id property becomes the customer ID,
preserved exactly, never renumbered. Satisfy becomes allocation,
verify becomes verification linkage, derive becomes derivation.
Custom requirement stereotype values are carried as attributes, since
they usually encode criticality, category or verification scheme.
Report the count of each relationship type converted, and any whose
ends could not both be resolved in the file.

VALUES AND UNITS: carry value properties across as typed variables
with units. Where the model uses a unit library, say which mapping
you applied. Where a value is untyped or its unit lives only in the
name, report it rather than guessing, and never silently assume SI.

DRY RUN, before any write: the survey, the export-quality findings,
the four-category table, counts to be created by type, the first five
and last five requirements in full exactly as they will land,
collisions, unresolved references, and everything in the
does-not-translate category. Reconciliation arithmetic:
  elements in file = imported cleanly + imported approximately
                   + carried as annotation + not imported
If the numbers do not reconcile, stop and say so. Suggest importing
into a branch so the whole migration can be discarded in one step.
Wait for approval.

IMPORT in dependency order: packages and types first, then structure,
then relationships. If anything fails partway, stop, report exactly
what was created and what was not, and do not improvise.

ON RE-IMPORT of a later export: match on the stored XMI id, never on
name. Report new elements, changed elements with both versions,
unchanged elements, and elements in Dalus whose source id is absent
from the new file. Never delete on the strength of an absence, since
a narrower export scope looks identical to a deletion. Report it and
let the user decide.

FINAL REPORT: the arithmetic against actuals; the four-category table
as executed; the unresolved references and what to re-export; custom
profile data carried as annotation and where it landed; and a plain
paragraph on how complete the migration is and what a human should
check first. Offer, do not execute: generating a specification
document from the migrated model so the team can compare it against
their Cameo report output side by side, publishing a stakeholder
review of the migrated model for people who cannot open Cameo, and
re-importing a later export as a drift check while both tools run in
parallel.

THIS WORKFLOW WRITES to the Dalus model, on a branch, after an
approved dry run. It never touches the Cameo project or the export
file.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions