[SysML] #3. Understanding Dependencies of Pkg Diagram

Dependencies in SysML are important to clearly represent the interdependencies between various parts of the system model. Dependencies represent connections between model elements and describe relationships in which changes to one element (provider) can affect another element (client). Clearly indicating these dependencies is key to the design and implementation of the system and future change management processes. Below we describe the main types of dependencies and their characteristics.

This image shows dependencies using in SysML in order to help understanding dependencies of Pkg Diagram
image 8
This is a Dependencies of package Diagram of Enterprise Architect. If you want to get more information about Dependencies of package Diagram, this article may be helpful.

Usage

  1. Description: A usage dependency indicates that a client uses functionality or information from a provider. This is a visual representation of the dependency that the client cannot perform its function without the provider.
  2. Example: If the ‘Speed Control’ function uses ‘Speed Sensor’ data, then ‘Speed Control’ has a usage dependency on ‘Speed Sensor’.

Refinement

  1. Description: A materialization dependency indicates that the client has more detailed information or implementation than the provider. This refers to relationships that advance the supplier’s conceptual or initial design to a more concrete level.
  2. Example: If functionality presented in the initial system design is refined during the detailed design phase, the detailed design has a refinement dependency on the initial design.

Realization

  1. Description: An implementation dependency indicates that the client implements the supplier’s specifications or definitions. It is mainly used to represent an implementation of an interface or a concrete implementation of an abstract class.
  2. Example: If ‘Driving Control System’ implements the specification of ‘Driving Control Interface’, then ‘Driving Control System’ has an implementation dependency on ‘Driving Control Interface’.

Trace

  • Description: Tracing dependencies represents the connection between a client and a provider and is used to trace the link from a specific requirement to a design or implementation element that satisfies that requirement.
  • Example: When a specific requirement is traced to an implemented system component, a trace dependency exists between the requirement and the component.

Allocate

  1. Description: Assignment dependency indicates that one model element is assigned to another model element. It is primarily used to express allocation of resources or assignment of responsibilities.
  2. Example: If a specific software component is assigned to a hardware platform, an allocation dependency exists between the software component and the hardware platform.


Import relationships in SysML play an important role in efficiently managing the structure of your model and establishing clear relationships between elements. This relationship contributes to increasing model clarity and maintainability, especially in large models or complex systems where multiple model elements interact. Below we will look at the types and notation of import relationships in more detail.

Package Import

  1. Description: Package import is used to import the contents of a package from one namespace to another namespace. This allows imported elements to be used directly within the target namespace, reducing the need for fully qualified names.
  2. Notation: Indicated by a dotted arrow when used with the «import» keyword. The direction of the arrow points to the source of the content being imported, with the destination namespace at the tail of the arrow.

Element Import

  1. Description: Import Element is used to import a specific model element from one namespace to another namespace. This allows you to effectively reuse and manage elements, even in complex models.
  2. Notation: Likewise indicated using the «import» keyword and a dotted arrow, any name conflicts can be resolved via aliases.

Use alias

  1. Description: If the name of an imported element conflicts with another element within the target namespace, an alias can be used to provide a unique name. This is an important way to avoid naming conflicts and maintain clarity within your model.

Visibility

  1. Description: Imported elements can have public or private visibility, which determines whether the element can be imported into other namespaces. The «access» keyword indicates the import of an element with private visibility, meaning that the imported element is only accessible within the target namespace.



In SysML, the concepts of views and perspectives play a central role in managing complexity and meeting stakeholder requirements through system modeling. Different stakeholders involved in a project have different interests and needs, and views and perspectives provide a mechanism to clearly demonstrate specific aspects of the model to meet their needs. This approach helps you easily navigate and understand important information in your model.

View

  1. Purpose: A view represents a subset of a model defined from a particular perspective and contains only the model elements and information of interest to the stakeholders of that perspective. This allows for a granular representation of specific aspects or features of the model.
  2. Application example: For example, from a security perspective of a system, views can be created that contain security-related model elements and information, allowing security personnel to easily review and evaluate the system’s security design.

Viewpoint

  1. Purpose: A perspective is a framework used to define a view, specifying the stakeholders’ interests, purpose, language used, and methods. A perspective provides guidance on how a view should be structured.
  2. Application example: By defining a performance perspective in a development project, you can construct a view that contains model elements related to the performance requirements of the system. This perspective will include performance metrics, analysis methods, and related metrics.

Conform Relationship

  1. Purpose: A conform relationship indicates that a view follows the rules and methods defined in the aspect. This relationship allows you to explicitly express whether a view satisfies the requirements of the viewpoint.
  2. Application example: A conformance relationship can be used to indicate that the ‘System Architecture View’ follows the rules and methods of the ‘Architectural View’. This shows that the view appropriately applies the modeling rules and language defined by the perspective.



In SysML modeling, package diagrams and block definition diagrams are used to represent different aspects of a system, with each diagram having a specific purpose and focus. To make it easier to understand, a package diagram focuses on organizing multiple ‘books’ (model elements) into categories, like ‘bookshelf in a library’. Block definition diagrams, on the other hand, are used to detail the ‘structure of a book’. Below we explain in more detail the context in which each diagram is used.

Package Diagram

  • Suitability for use: Package diagrams are ideal when you want to clearly express the logical structure of your system and the relationships between packages. In particular, use it when you want to visualize the organization of the multiple modules or packages that make up a system and the dependencies between them.
  • Application example: When you want to get an overview of the entire system, you can show how the main modules are connected to each other, for example, ‘communication system’, ‘data processing system’, ‘user interface’, etc.

Block Definition Diagram

  • Suitability for use: Use BDD when you want to show the details of the individual elements that make up a system and the relationships between them. It is especially suitable when you want to express in detail the properties, operations, and relationships between elements (e.g. associations, generalizations, etc.) of components.
  • Application example: It can show in detail which ‘sensors’ and ‘actuators’ the ‘engine control unit’ in the system uses and what the interface between them is.

Determining factors

  • Stakeholder Needs: Consider who will use the diagram and choose the appropriate diagram type based on the information your stakeholders will be interested in.
  • Nature of information you want to express: If you want to show the ‘overall structure’ of the system, choose pkg, and if you want to show ‘detailed structure and relationships’, choose bdd.
  • Purpose of modeling: Use pkg if your goal is to provide a high-level structural view of the system, or bdd if your goal is to clarify the system’s components and their details.

In conclusion, package diagrams and block definition diagrams play complementary roles in SysML modeling and can be used together to effectively represent various aspects of a system. It is important to understand the focus and purpose of each diagram and utilize it appropriately according to the project’s requirements and stakeholder interests.


The package hierarchy you construct has a significant impact on the understandability, maintainability, and scalability of your model. Here we will introduce examples of each configuration method applied. These examples illustrate different approaches to system modeling.

Example of configuration by system layer

  1. Systems: Contains high-level design and policies for the entire system.
  2. Subsystems: Each subsystem that makes up the overall system, reflecting the major functional areas of the system. For example, there may be ‘driving control system’, ‘communication system’, etc.
  3. Components: Indicates the major components that make up each subsystem. For example, there may be a ‘speed sensor’, ‘direction control logic’, etc. within the ‘driving control system’.
  4. Parts: Each component is further broken down and contains specific implementation details.

Example of configuration by process life cycle

  1. Requirements: A package containing system requirements, including functional and non-functional requirements.
  2. Design: A package responsible for the design phase of the system, including architectural design and detailed design.
  3. Implementation: A package responsible for the implementation phase of the system, including code implementation, test cases, etc.

Example of composition by team

  1. Requirements Team: A package containing the work of the team responsible for requirements analysis and management.
  2. Design Team: A package containing the work of the team responsible for designing the system.
  3. Quality Assurance Team: A package containing the work of the team responsible for quality assurance and testing.

Example configuration by model element type

  1. Requirements: Contains elements of the system’s requirements model.
  2. Behaviors: Contains model elements that describe the behavior of the system, such as activity diagrams, state machines, etc.
  3. Structures: Contains model elements that describe the structure of the system, such as block definition diagrams, internal block diagrams, etc.

Example of composition by possibility of change

  1. CoreSystem: A package that contains the core functionality of the system and is unlikely to change.
  2. AdaptableModules: A package containing modules that can be changed depending on the needs of the system.

Configuration example by reuse support

  1. CommonLibraries: A package containing libraries and elements that can be commonly used across multiple projects.
  2. ProjectSpecific: A package that contains elements used only for a specific project.



[SysML] #1. Understanding SysML Diagrams

[SysML] #2. Understanding SysML Package Diagram

[SysML] #4. How to draw a Pkg Diagram with EA

[SysML] #5. Understanding SysML Requirement Diagram

[SysML] #6. Understanding Relations In Req Diagram

[SysML] #7. How to draw a Req Diagram with EA

[SysML] #8. Understanding SysML UseCase Diagram

[SysML] #9. How to draw a UseCase Diagram with EA

[SysML] #10. Understanding SysML bdd Diagram

[SysML] #11. Understanding SysML ibd Diagram

[SysML] #12. Understanding Part Property of Block

[SysML] #13. Understanding Reference Property of Block

[SysML] #14. Understanding Value Type

[SysML] #15 Understanding Parametric Diagram

[SysML] #16. Understanding Flow Property

[SysML] #17. Understanding Port and Association Block

[SysML] #18. Understanding Behavior of Block

[SysML] #19. Understanding Generalizations

[SysML] #20. Understanding Dependencies, Allocate, Comment

[SysML] #21. Understanding Activity Diagram

[SysML] #22. How to draw a Activity Diagram with EA

[SysML] #23. Seq Diagram LifeLine and Message

[SysML] #24. Seq Diag Constraints Fragment Decompose

[SysML] #25. How to draw a Sequence Diagram with EA

[SysML] #26. Understanding Stm Diagram State and Transition

[SysML] #27. Understanding Stm Diagram Event Pseudostate Region

[SysML] #28. How to draw a State Machine Diagram with EA

Leave a Comment