Package Ownership and Shared Libraries in a Radar Product Line
A 60-person systems engineering group maintains a SysML model for three variants of a ground surveillance radar. The repository has 14 top-level packages, but engineers place new blocks in whichever package is open, so a 'PowerInterface' block appears in four packages with slightly different ports. Diagram frames reference elements across package boundaries, and a recent package rename broke 23 diagrams. Shared libraries for units, interfaces, and requirement templates are used by all variants; variant-specific behavior and hardware belong to only one product. The modeling tool enforces package ownership, supports read-only library plugins, and has no automatic refactoring. A configuration audit is six weeks away. The lead wants an organization that reduces duplication and preserves traceability without freezing variant work. Some engineers propose a single 'Common' package for everything shared and a 'Variants' package for the rest; others want one package per variant with copies of shared elements.
1. Evaluate the two proposals. Recommend a top-level package structure and explain where shared interface definitions, unit libraries, requirement templates, and variant-specific behavior belong. How should variants reference shared content?
Read the worked answer
Both proposals fail for different reasons. A single 'Common' package becomes an unstable dumping ground: every shared change forces all variants to re-baseline, and ownership is unclear. One package per variant with copies breaks element identity: a copied interface is a different model element, so traceability, change impact, and configuration audit cannot follow the real interface. A defensible structure is layered by purpose:
00_Libraries: units, value types, interface definitions, requirement templates, and reusable blocks. Put this under configuration control and expose it to projects read-only through the tool's library plugin.10_ProductLine: common radar architecture and common requirements shared by all variants.20_Variants/VariantA,VariantB,VariantC: only variant-specific hardware, behavior, and requirements.30_Verification: test cases and verification plans.40_Views: diagram frames and queries for reviews.
Variants should import the library packages via package import (or element import for a few elements), not copy elements. The key reasoning is that a shared block type can be reused by many parts; composition in a variant does not duplicate the type. Keep one qualified name per shared element and make cross-package dependencies explicit.
2. Some engineers want to apply a stereotype to mark blocks as 'approved' or 'variant-specific' and to stop edits. Is that appropriate? What should handle edit control instead?
Read the worked answer
A stereotype is appropriate for metadata that the language does not already carry: for example, a «modelStatus» stereotype extending Block with properties such as status, approvalDate, and approver. Applied to a block, it lets views and reports filter approved vs draft content, and it is visible in the model. It is not appropriate to use the stereotype as the access-control mechanism. Stereotypes annotate elements; they do not reliably enforce permissions, and a user can remove or change the stereotype. Edit control should come from package ownership plus tool configuration: libraries are read-only, variant packages have named owners, and baselines are locked at audit points. Also avoid creating a stereotype for 'variant-specific' if package location already expresses that fact; redundant tags drift. Use the stereotype only where the status is not derivable from package or configuration. A view can then select blocks with status=approved without moving them.
3. A package rename broke 23 diagram frames. What practices prevent this, and how should diagrams be organized?
Read the worked answer
The breakage is a symptom of treating diagrams as owned content rather than views. Diagram frames should reference elements by qualified name; when a package is renamed, the tool must refactor references, not just rename the container. Practices: (1) keep diagram frames in view packages, not scattered inside the packages they depict; (2) avoid moving elements between packages unless ownership is genuinely changing; (3) use package import for cross-package references so qualified names remain stable; (4) run model validation and dependency reports before renaming; (5) use the tool's refactoring command and a baseline diff. For the 23 broken frames, repair by restoring the qualified name or running refactoring, then move the diagrams into 40_Views organized by viewpoint. Do not fix them by copying elements into the diagram's package; that creates duplicates and hides the dependency.