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

When we start a project using Enterprise Architect (EA), we encounter a top-level package named ‘Model’. This ‘Model’ is the forge of the project, the place where all the ideas and structures come together.

Role of Model Type Package

The ‘Model’ Package is the core container of the project, and it contains all the elements and structures of the system. Especially when developing a single system, there is usually only one Package of this Model type and it forms the basis of the project. However, if the system has a complex structure consisting of multiple subsystems, you may need to consider a strategy of adding multiple Model Packages from a ‘System of Systems’ perspective.

Add Model

Adding a Model Element through the Package Diagram’s Toolbox is simple. However, one thing to note is that the Model basically has a similar shape to the Package Element, but it has a special triangle mark in the upper right corner. This is a visual signal that distinguishes a Model type package from a regular package. Additionally, in the Project Browser, these Model Packages are displayed with tags starting with ‘<>’, which helps EA identify the Model Type Package.

image 5

When using tools such as Enterprise Architect (EA), it is important to define the structure and perspective of modeling, and this is done through the ‘View Type Package’.

Basics of View Type Package

In EA, it is impossible to add diagrams or elements directly to the top node, ‘Model’ (Root Node). This is only possible through ‘Package’, and if you add a package to the model, a ‘View Type Package’ is created. This View is a package that represents a specific aspect or perspective of a system model and plays a major role in organizing and clearly classifying the various elements of the model.

Role and meaning of View

EA is intentionally designed to add Views as child elements of Model. This reflects that an effective methodology is to divide the system (Model) we want to develop into various view units during the modeling process. Each View focuses on a specific part or aspect of the system, which provides a clearer understanding of the overall structure and behavior of the system.

Real world example: structural classification of car models

For example, let’s consider creating a ‘Structure View’ under a model (Root Node) called ‘CAR’. This Structure View focuses on the structural classification of cars and provides a perspective on how to organize and represent the various components of a car. Using Views in this way clearly separates the various aspects of a complex system, helping you understand how each part contributes to the overall system.

In Enterprise Architect (EA), Package is the fundamental building block of a SysML model. It is a space where all diagrams and elements can be created, and it plays an essential role in organizing the structure and logic of the system. We start by creating a Package Tree through the ‘New Package’ function in the Project Browser.

This Package Hierarchy is helpful understanding how to draw a pkg diagram with EA

Package diagram for structural classification

For example, create a Package Diagram named ‘Structure’ under ‘Structure View’. Afterwards, add packages such as ‘body’ and ‘chassis’ to the diagram by dragging and dropping them through the Project Browser. During this process, a pop-up will appear asking what form you would like to add the package to the Package Diagram, and select Add in the basic form (Package element).

image 7

Improved informativeness of diagrams

The package diagram created by default has limitations in providing information because it does not immediately show the elements contained in each package. To solve this, if you check ‘Package Contents’ using the Compartments tab in the Diagram’s Properties window, you will be able to see the Elements inside each package. This greatly improves the informativeness of the diagram. (If the Properties window is not activated, click Start → All Windows → Properties → Properties to activate it.)

image 8

Containment relationship and hierarchy

The containment relationship indicates that one package contains another package, and is used to clearly express the hierarchy of the system. For example, create a new ‘Structure2’ Package Diagram under ‘Structure View’, add the ‘body’ package to this diagram, and then create a containment relationship from the ‘design’ package to the ‘body’ package. This relationship visually indicates that the ‘design’ package contains the ‘body’ package.

In EA, you can easily check the inclusion relationship between packages in the Project Browser, but in order to output the model as a document and provide it to stakeholders, it is necessary to express the configuration relationship between packages through a package diagram.

For reference, you can drag the design package with the containment relationship connected and place it into the body package. (The body package icon must be large enough.) In this way, you can use the containment relationship to display the nesting relationship of elements at various depths.

image 9
This is a Package Diagram drawn with Enterprise Architect. If you want to get more information about Package Diagram, this article may be helpful.

Namespace is used to indicate the location and membership of each element within the system model. By using correct Namespace notation, you can clearly distinguish between elements with the same name when they exist within different components.

Practice example: Block addition and namespace problem

For example, after adding a Block named ‘Block2’ to the ‘suspension’ package, add a package diagram called ‘design’ to the ‘body → design’ package, and link ‘Block2’ to the ‘design’ package diagram. Add. In this case, the name of ‘Block2’ is displayed as ‘suspension::Block2’. This indicates that ‘Block2’ is within the ‘suspension’ Namespace, but the full path to ‘chassis::suspension::Block2’ is missing.

image 10

How to improve namespace notation

To make the namespace notation clearer, enable the ‘Fully Qualified Namespace’ option in the Diagram’s Properties window. If you select this option, the full path of the element will be clearly displayed within the diagram. This allows you to identify the exact location of each element without confusing it with other elements with the same name.

image 11

If you look at the SysML Model section of the Package Diagram’s Toolbox, there are View, View Point, and Stakeholder elements. To explain each again:

  1. View: View is an element that expresses a specific aspect or function of the system. It is based on perspectives and requirements defined by a specific Viewpoint. Views can cover many aspects of a system, including its structure, behavior, and requirements, and focus on the specific concerns of stakeholders. For example, there is a structural view that shows the physical composition of the system, a behavioral view that describes how the system operates, etc.
  2. View Point: Viewpoint defines a specific perspective from which the system is viewed. It provides rules, methodologies, and criteria to follow when creating Views. Viewpoints help you determine which aspects of the system are important and what information should be included. In addition, it specifies which views are needed in the system modeling process, reflecting the requirements and interests of various stakeholders.
  3. Stakeholder: Stakeholder refers to an individual, group, or organization that has an interest in the system. They influence or are affected by the design, development, and operation of the system. Stakeholder requirements, expectations, and goals play a very important role in the system modeling process, and views and viewpoints are used to reflect them. Stakeholders are key targets that must be satisfied for successful design and implementation of the system.

Meeting the requirements of complex systems through the modeling process is always a challenge. However, a systematic approach using SysML makes this process much easier. The modeling sequence and relationship definitions described here are key to the success of the project.

Step 1: Identify Stakeholders and Define Their Interests

The first step in system modeling always begins with identifying stakeholders and understanding their interests. In this example, we have identified ‘Driver’, the user of the car, as the primary Stakeholder. Driver’s main concerns are speed and quality – a vehicle that is both fast and trouble-free. These defined stakeholder interests provide a reference point for setting project goals.

Step 2: Creation of Viewpoint

Reflecting the interests of each stakeholder, we create two viewpoints: speed and quality. These Viewpoints provide specific perspectives to consider in system modeling and provide guidance on what elements should be included in the model and how the system should be designed.

image 12

Step 3: Definition of View and Setting Confirm Relationship

Define the view corresponding to each viewpoint. These views visually represent the model elements of the system that satisfy the requirements presented by each viewpoint. In this process, a Confirm relationship is established between each View and its corresponding Viewpoint. This relationship explicitly states that the View meets the requirements of the Viewpoint.

image 13

Step 4: Connect model elements through Expose relationships

In the final step, the model elements included in each view are connected through an Expose relationship. This relationship clarifies how model elements are related to each other within a particular View, making the definition and composition of the View clearer. In particular, the Expose relationship between View type package and View elements is important for understanding the structure of the system and the interactions between elements.

image 14

EA’s Model View feature is a very useful tool when performing system modeling. This feature allows quick access and efficient management of specific diagrams or elements within complex models. You can do this through the Model Views tab in the Focus window, and here I’ll give you an overview of how you can take advantage of EA’s Model View functionality.

Activation of Model View feature

To use the Model View function in EA, you must first activate the Focus window. This can be accessed via ‘Start → All Windows → Design → Focus’, following this path will bring up the Focus window within EA’s user interface.

Actions in the Model Views tab

The Model Views tab within the Focus window allows users to gather diagrams and elements they consider important within the model. By adding new views under this tab and assigning diagrams or elements of interest to these views, users can easily manage and access frequently referenced items within a project.

Reference material

More detailed information and how to use EA’s Model View feature can be found on Sparx Systems’ official documentation page and my blog. These materials provide practical tips and guidance to EA users, making the modeling process more efficient.

Sparx Systems official documentation: Accessing the Repository Using Model Views
My blog: EA13 Project Browser and Focus Window

SysML relationship types represent various types of connections between components in a system. Effective use of these relationships in Enterprise Architect (EA) is important to ensure model accuracy and understanding. There are four core relationships called Dependency, Import, Realization, and Refine. Since there is no major difficulty in using them in EA, I will briefly explain each type.


  1. Definition: Dependency is used when one element depends on the definition or implementation of another element. This relationship is useful for tracking the impact of change and indicates when one element would not be able to exist without the other.
  2. Use case: For example, if one feature of your system depends on data from another service, you can establish a Dependency relationship between these two elements.


  1. Definition: Import relationship is used when you want to use an element defined in one package in another package. This helps increase code reusability and reduce model duplication.
  2. Use case: When you want to reuse the functionality of a common utility package across multiple system modules, you can express this using an Import relationship.


  1. Definition: Realization refers to how one element (usually an interface or specification) is realized by another element (an implementation). This relationship expresses the connection between an abstract definition and a concrete implementation that satisfies that definition.
  2. Use case: By establishing a Realization relationship between the definition of an interface and the block that implements it, you can make it clear that the implementation satisfies the specification.


  1. Definition: A Refine relationship indicates that the specification of one element is further refined or improved upon by another element. This is usually used to evolve requirements into a more specific design or implementation.
  2. Use case: You can use Refine relationships to evolve high-level system requirements into more detailed design elements.

These relationship types play an important role in clearly expressing the connections and dependencies between elements when performing system modeling in EA. When used correctly, these relationships help make the model more understandable and clearly communicate design intent.

This concludes the posting of Package Diagram. Although the content is insufficient, I would like to thank all the readers who have read this far. In the next post, we will cover Requirement Diagram.

[SysML] #1. Understanding SysML Diagrams

[SysML] #2. Understanding SysML Package Diagram

[SysML] #3. Understanding Dependencies of Pkg Diagram

[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