XMI Round-Trip, Import Visibility, and Value Types Across Two Code Generators

Tag values do not travel as free-floating annotations. They exist because a profile is applied to a package, the profile defines a stereotype extending a metaclass, and the model contains stereotype applications whose slots hold the tagged values. If the receiving tool sees only the stereotype name without a resolvable profile application, it has nowhere to put currency and scale and silently drops them. The UML 2.4 target compounds this: profile application and stereotype representation differ from UML 2.5, so an export that relies on 2.5-specific serialization may be unreadable even though the class diagram looks intact. Fix the exchange contract: export with the profile definition included or referenced by a stable URI, ensure ProfileApplication is present on the owning package, export stereotype applications explicitly, and validate a round-trip on a small fixture before the full model. Add a post-import check that asserts every Money instance has both tag values. Downgrade the interchange format to the target's supported XMI version at the boundary rather than asking the target to guess. Do not hand-patch tag values after import; that hides a repeatable process defect.

Both are PackageImport variants, but they differ in re-export. «import» makes the imported members visible in the importing namespace and, in UML's public import sense, makes them part of that namespace's visible content, so downstream packages that import Billing may see CommonTypes names transitively. «access» makes the names available inside Billing but does not re-export them; Billing's clients do not acquire a dependency on CommonTypes merely by importing Billing. For a shared foundation library, Billing should use «access» unless its own public API exposes CommonTypes types; if Billing's public signatures mention Money, clients need visibility, so the dependency must be deliberate and documented, not accidental. Ordering's public import can leak CommonTypes into Ordering's exported namespace, causing name collisions and coupling. The practical rule: choose «access» for implementation-only use, choose «import» only when the imported types appear in the public contract, and check generated package/namespace declarations to confirm the tool honors the distinction. This matters for independent module evolution and for avoiding a transitive re-export of a platform-wide type library.

Money has value semantics: two instances with the same currency and amount should be equal, and identity is irrelevant. Model it as a DataType, preferably with amount and currency as typed attributes and any operations defined on the type, not as a mutable Class. A DataType signals to generators that value comparison, copying, and immutability are expected; a Class with a mutable amount encourages reference equality and shared mutation. The defect follows directly: Billing compared references, so two Money values representing the same amount were treated as different keys, and invoice deduplication failed. Changing the model alone will not repair existing generated code; add equality and hashing generation or a hand-written value type, and add a regression test that constructs equal Money values independently and asserts equality. Also reconcile Routing's interpretation: if one module treats Money as a DataType and another as a Class, the generated APIs will not interoperate cleanly. Standardize CommonTypes as the single definition and have both generators import that definition rather than restating it.