1.2 Model Organization, Packages & Viewpoints

1.2 Model Organization, Packages & Viewpoints

Quick Reference: Packages (pkg) structure the model repository into manageable namespaces. Elements possess an ownership hierarchy accessed via the double-colon :: operator. Public (+) elements can be shared across packages using «import» dependencies, while private (-) elements remain encapsulated. Stakeholder-specific perspectives are managed through views that conform to viewpoints, a concept SysML 1.2 bases on IEEE 1471.

---

The Necessity of Model Organization

Industrial systems models for aircraft, spacecraft, automobiles, or medical devices contain tens of thousands of model elements—Blocks, ValueTypes, Requirements, State Machines, Activities, and Interfaces. Without a disciplined organizational architecture, a model rapidly degenerates into an unmaintainable tangle where engineers cannot locate components, duplicate definitions proliferate, and multi-team collaboration breaks down.

SysML addresses model scalability through Packages and Package Diagrams (pkg). Model organization provides three essential engineering capabilities:

1. Namespace Isolation: Preventing naming collisions between disparate subsystems (e.g., distinguishing between an electrical Battery and a hydraulic Accumulator).
2. Configuration Management & Access Control: Partitioning models into modular units suitable for version control branching, access control, and independent team ownership.
3. Multi-Stakeholder Communication: Presenting filtered, role-tailored views to safety certifiers, software engineers, thermal analysts, and program managers without overwhelming them with irrelevant architectural details.

---

Packages as Namespace Containers and Ownership Boundaries

A Package is a fundamental SysML model element that serves as a general-purpose container for grouping related model elements. Graphically, a package is rendered as a folder icon—a large rectangle with a smaller rectangular tab affixed to its upper-left corner.

The Strict Ownership Rule

In SysML, model elements do not float unanchored in the repository. Every model element must be owned by exactly one namespace (except the root model itself).

• Lifecycle Cascading: Package ownership defines lifecycle coupling. If a package is deleted from the model repository, all elements owned by that package—child packages, blocks, activities, requirements, diagrams—are permanently deleted with it.
• Design-Time vs. Runtime: A package is strictly a design-time organizational container. A package is never instantiated into a physical runtime object. You cannot assign ports, parts, or runtime states to a package; those capabilities belong exclusively to classifiers like Blocks.

Package Naming and Tab Syntax

SysML supports two graphical conventions for displaying a package name:

1. Name in the Body: When the package body contains no visible inner elements or diagrams, the package name is centered in large text directly inside the main rectangular body.
2. Name in the Tab: When the package body contains inner elements (e.g., child packages, blocks, or diagrams), the package name is placed inside the upper-left tab, leaving the main rectangular body clear for displaying its contents.

---

Element Visibility: Public (+) versus Private (-)

Elements owned by a package have an assigned visibility that dictates whether elements outside that package can access or reference them. SysML defines two primary visibility levels for model organization:

+-----------------------------------+
| FlightGuidancePkg                 |
+-----------------------------------+
| + AutopilotComputer [Block]       |
| + GuidanceLaw [Activity]          |
| - InternalKalmanFilter [Block]    |
| - SensorBiasMatrix [ValueType]    |
+-----------------------------------+

In the example above, external engineering packages can reference AutopilotComputer and GuidanceLaw, but cannot reference or instantiate InternalKalmanFilter or SensorBiasMatrix because they are marked with private (-) visibility.

---

Fully Qualified Names and the Double-Colon Operator

Because packages establish isolated namespaces, two completely different model elements can share the identical simple name as long as they reside in distinct packages. For example, both the avionics team and the propulsion team may define a Block named Controller.

To distinguish between them unambiguously, SysML employs Fully Qualified Names (FQNs) constructed with the double-colon (::) path delimiter:

RootModel::ParentPackage::ChildPackage::ElementName

Worked Example: Disambiguating Identical Names

Consider an aircraft architecture model:

• AircraftModel::AvionicsPkg::FlightControl::Controller
• AircraftModel::PropulsionPkg::FuelManagement::Controller

Both elements are named Controller, yet their fully qualified names prevent any ambiguity in behavioral allocations, interface typings, or requirement satisfaction matrices.

---

Package Hierarchies and Graphical Containment Notations

Packages can be organized into multi-level containment hierarchies where a parent package owns one or more child packages. SysML provides two visually distinct yet semantically identical graphical notations to depict namespace containment on a Package Diagram (pkg):

1. Physical Nesting (Box-in-Box Notation)

The child package folder is drawn physically inside the boundary of the parent package rectangle. This notation is intuitive for small hierarchies but can become visually cluttered when modeling deep nesting.

2. Circle-Plus Connector Notation

A separate child package box is drawn outside the parent package. A solid line connects the two packages, featuring a distinctive adornment at the parent end: a circle enclosing a plus sign ((+)).

+-----------------------+              +-----------------------+
| ParentPackage         |              | ChildPackage          |
|                       |--------------|                       |
+-----------------------+(+)           +-----------------------+

Exam Warning: The circle-plus symbol MUST always be positioned at the parent (container) end of the line. Placing the circle-plus at the child end is an invalid notation frequently used as an incorrect distractor on certification exams.

---

Package Relationships: Imports and Dependencies

Packages interact across namespace boundaries using two primary directed relationships: Package Import and Package Dependency.

Package Import («import»)

A Package Import is a directed relationship drawn as a dashed arrow with an open arrowhead pointing from the importing (client) package to the exported (supplier) package, labeled with the stereotype «import».

• Namespace Merging Semantics: Package import adds the public (+) elements of the supplier package directly into the namespace of the client package. (SysML 1.2's notation table shows a public import with the keyword «import» and a private import with «access».)
• Eliminating the :: Path: Once PackageA imports PackageB, elements inside PackageA can refer to public elements of PackageB directly by their simple names, without needing to write PackageB::ElementName.
• Private Elements Remain Sealed: Private (-) elements in PackageB are never imported. They remain strictly hidden and inaccessible to PackageA.

Package Dependency («dependency» or Unlabeled Dashed Arrow)

A standard Package Dependency indicates that one or more elements within the client package rely on the definitions, presence, or structure of elements within the supplier package.

• Unlike «import», a general dependency does not merge namespaces; client elements must still use fully qualified names (SupplierPkg::Element) or have an explicit import.
• A dependency signals to configuration managers that if the supplier package is modified, the client package may require re-verification or re-engineering.

---

Special Package Types: Model, Model Library, and Profile

SysML defines specialized stereotypes applied to packages to convey specific architectural roles:

---

Views and Viewpoints (IEEE 1471 Concepts in SysML 1.2)

Complex engineering projects involve diverse stakeholders with conflicting concerns:

• Thermal Engineers care about power dissipation, heat transfer coefficients, and airflow velocities.
• Software Architects care about thread concurrency, memory allocation, and message queues.
• Safety Certifiers care about failure rates, fault containment zones, and single-point failure modes.
• Program Managers care about bill-of-materials costs, supplier delivery schedules, and component maturity.

Presenting the entire system model to any single stakeholder creates cognitive overload. SysML 1.2 extends UML's view and viewpoint concepts "to be consistent with the IEEE 1471 standard" (the architecture-description standard later superseded by ISO/IEC/IEEE 42010). It uses two connected elements: «viewpoint» and «view».

The Viewpoint («viewpoint»)

A Viewpoint is a formal specification of the conventions, rules, diagram kinds, and modeling techniques required to construct a view that addresses specific stakeholder concerns.

A Viewpoint is a specification/template, not the data itself. SysML 1.2 gives it five string attributes:

• stakeholders: The roles or groups whose interests are addressed (e.g., Safety Auditor).
• concerns: The specific engineering questions being evaluated (e.g., Hazard mitigation and redundant power failover).
• purpose: The rationale for generating the view.
• languages: The modeling syntax employed (e.g., SysML v1.2).
• methods: The methods used to construct views for this viewpoint. SysML itself does not define these methods.

The View («view»)

A View is a stereotyped package, "a representation of a whole system or subsystem from the perspective of a single viewpoint." In SysML 1.2 a view may own only element imports, package imports, comments, and constraints, so it brings model content in by importing it rather than owning it. Its symbol is a package labeled «view», optionally showing {viewpoint=ViewpointName}.

The Core Structural Relationships:

1. «conform» Dependency: The View conforms to its Viewpoint via a directed dashed dependency arrow: View ----«conform»----> Viewpoint. SysML 1.2 requires the client to be a «view» and the supplier a «viewpoint»; the view's derived viewpoint property comes from this dependency.
2. Imports (not «expose»): In SysML 1.2 a view gets its content through element and package imports, e.g., View ----«import»----> SystemPackage. The «expose» relationship that newer tools show was introduced in SysML 1.4, after the 1.2 version this exam covers.

+-------------------+                         +-------------------------+
| «view»            |                         | «viewpoint»             |
| ThermalView       |------«conform»--------->| ThermalAnalysisVP       |
+-------------------+                         +-------------------------+
          |                                   | stakeholder: Thermal Eng|
          | «import»                          | concern: Heat Dissipat. |
          v                                   +-------------------------+
+-------------------+
| BatterySubsystem  |
+-------------------+

---

Exam Pitfalls & Misconceptions