Packages & Package Diagrams allow the organization of a model by containing model elements within packages.
Packages & package diagrams may be useful to help convey your model’s organizational structure to internal and external stakeholders. These diagrams are not mandatory for a comprehensive systems architecture but it may help stakeholders gain context of the model’s decomposition.
Best Practices with Packages & Package Diagrams
Ideally, your model’s package structure should contain the following packages: Requirements, Functionality, Performance, and Structural and Interface. This structure follows a standard systems architecture domain decomposition. This implementation enables an intuitive nature, while segmenting the model into potential disciplines of a system.
Key Elements & Relationships of Packages & Package Diagrams
On a Profile Diagram, some of the primary elements that are leveraged are Packages and Class Objects such as System Blocks, Subsystem Blocks, or Blocks. The use of each of the following elements should be relatively straight forward.
When developing the organizational hierarchy of your model it is important to know that you will be inherently creating “Containment” relationships as elements are created within other elements.
Package
A Package is in essence the containing folder of model elements. Typically Packages are a way of organizationally structuring your model. It should be noted that packages should not impact the organizational hierarchy of your system.
Profile
A Profile Package is a containing folder of stereotypes and customizations. Profile Packages should be used to contain these model elements to prevent validation rules from being identified as an error.
Containment
A Containment Relation is the relationship that shows an elements containment within another model element. Containment can either be shown as an encapsulation or via a nesting representation.
Things to Consider for Packages & Package Diagrams
Model External Stakeholders
If external stakeholders will be accessing the model after initial development, the organizational structure
should be relatively simple to follow. The more intuitive a models organizational structure is, the easier it will
be to find and modify elements of the system architecture.
Model Development Contributors
During the development of a complex system architecture, it would be beneficial to have the model decomposed
so that multiple individuals can make changes without stepping on each other.
- Organizational Segmentation – Requirements specialists can control a package of requirements of a system,
while the mechanical and electrical engineers can control design constraints. - Model Security – All engineering disciplines do not need to have the ability to change all aspects of the system
architecture. From a security perspective, engineering disciplines only need to have access to their
applicable section.
The implementation of packages allows an administrator the ability to control access of packages and prevent unauthorized changes from being made.
Ease of Navigation
Model organization is essential for efficient and effective communication, navigation & development.
Development Consistency
An organized model allows development privileges to be implemented while resulting in consistent & authorized modeling privleges to be followed.
Pingback: Model Organization - Beyond MBSE
Pingback: Creating Package Diagrams - Beyond MBSE