Designing and Generating Interoperating Modules
What the domain tests
This domain tests modular design in UML 2.5: components, interfaces, ports, connectors, packages, imports, substitutions, artifacts, and deployment. The goal is interoperating modules whose contracts are explicit and whose physical packaging is traceable.
Core rules
- A Component is an indirectly instantiated Class. It provides and requires Interfaces, usually through Ports. A required interface is a formal contract, not a usage arrow.
ComponentRealizationconnects a Component to the Classifiers or Interfaces that realize it.Substitutionstates that one Classifier can replace another at a collaboration point.PackageImportandElementImportadd references; visibilitypublicre-exports,privatedoes not.PackageMergecombines definitions and is used mainly for metamodel extension.- An Artifact
manifestsa Component; a Deploymentdeploysan Artifact on a Node.
Worked example
A PaymentService component provides PaymentIF and requires LedgerIF. PaymentAdapter realizes PaymentIF. Package payments publicly imports ledger::LedgerIF; artifact payment.jar manifests PaymentService; the artifact is deployed on AppServer. Reasoning: clients depend on PaymentIF, not on the adapter; substituting PaymentAdapter for another realization is valid only if it keeps the provided contract; the public import lets payments clients see LedgerIF; manifestation and deployment are separate links.
Traps
Do not draw an assembly connector as a plain dependency; it wires required to provided. Do not confuse import with merge: import references, merge combines. A required interface is not a usage dependency. An artifact is a physical file, a component is a logical unit. Private imports are not re-exported, so downstream packages may fail to compile.