[SysML] #12. Understanding Part Property of Block

쉬운 목차

Understanding Part Property of Block

In this blog post, we will take a closer look at Part Properties, one of the important elements of SysML (Block Definition Diagram). This component plays a key role in understanding the structural modeling of complex systems in systems engineering.

Understanding Part Properties

Part Properties are used to define the characteristics of each part that makes up the system. This is a tool that clearly shows how the various components within a system are connected and what role each plays in the overall system. For example, when modeling a car, each part, such as the engine, transmission, and wheels, can be expressed as Part Properties to explain the interaction and function within the system.

Understanding whole-part relationships

Whole-part relationships are expressed in SysML using Part Properties. This relationship is an important concept in understanding and designing complex systems, showing how the parts fit together to form the overall system.

Example of automotive system

Let’s take the example of modeling a car. A car is a block as a whole, and the engine and wheels are expressed as parts of this car. Here, a car is a larger functional system made up of engines and wheels. This structure is often seen in BOM (Bill of Materials), making the contribution and function of each part clear.

Physical assembly relationship

In physical systems, the whole-part relationship implies an assembly relationship. In other words, the entire block is made up of several partial blocks combined. This clarifies the structural position and role of each part and forms essential relationships when integrating the system.

Whole-part relationships in software

Whole-part relationships are also important in software systems. For software objects, the life cycle of the entire object directly affects its sub-objects. For example, when an entire object is deleted, all subobjects associated with it are also deleted. This is managed through aggregation and composition relationships in object-oriented programming.

Part Properties and Instantiation

Similarities to object-oriented programming

In object-oriented programming, classes serve as templates for creating objects of a specific type. Fields of this class sometimes consist of instances of other classes. Similarly, in SysML, the Part Properties of a particular block represent an instance of its Type. For example, if you have a class ‘Car’, this class could contain instances of the classes ‘Engine’ and ‘Wheel’ as fields. This applies equally to SysML, where the ‘Car’ block includes instances of ‘Engine’ and ‘Wheel’ as Part Properties.

The importance of instantiation

When a block is instantiated, its Part Properties must also be instantiated. This process depicts the specific function and structure of the system, with each Part Property representing an actual implementation of that type. For example, when a ‘Car’ block is instantiated, the included ‘Engine’ and ‘Wheel’ are also instantiated respectively, acting as components of the overall ‘Car’ instance.

Differences from composite block instances

Compound block instances with Part Properties are different from single block instances. A composite block instance internally contains other instances, each of which contributes to the overall functionality of the composite block. On the other hand, regular block instances have independent functionality and do not function within the context of other instances.

Expression method of Part Properties

Default format

Part Properties are expressed in the Part Compartment of a block in the following format:

<part name> : <type> [<multiplicity>]

Part Name : This is a freely configurable name depending on the modeling object and is used to identify the Part Property.
Type : Type refers to another block defined within the system and specifies the type of element that the Part Property represents.

Description of Multiplicity

Definition : Multiplicity refers to the number of instances the Part Property can contain. It can be expressed as a single integer or a range of integers.
Lower bound : Represents the minimum number of instances, expressed as 0 or a positive integer. A value of 0 means that instances of that part are optional.
Upper bound : Represents the maximum number of instances, expressed as 1, a majority (‘*‘), or a positive integer equal to or greater than the lower bound. ‘*’ means allow infinite instances. The default value is 1..1, which applies when Multiplicity is not specified.

Visual understanding of Part Properties

Car model example

Let’s assume. Let’s say the Car block contains four Wheel Part Properties. The way to express this is wheel : Wheel [4], which indicates that the car has 4 wheels. here:

wheel is the name of the Part Property.
Wheel indicates what type of block this Part Property is, in this case it refers to the ‘Wheel’ block.
[4] stands for Multiplicity, meaning the car is equipped with four wheels.

Multiplicity and Unique Settings

In the example above, the Multiplicity value [4] means that the car needs exactly four wheels. The {unique} setting is a UML notation that specifies that each of these wheels is a distinct entity. This setting is used when each instance must be unique and duplication is not allowed. In SysML, you can increase model precision through these settings.

Definition and Importance of Composite Association

Definition

Composite Association is a connection that represents a whole-part relationship between two blocks. In this relationship, ‘whole’ is located at the end of the composite and ‘part’ is located at the end of the part. This connection is important when managing the complexity of the system and clarifying the role of each part.

Block relationship

In this connection, the block located at the partial end is considered the Part Property of the block located at the composite end. This means that partial blocks act as components of the whole block, and have a significant impact on the function and structure of the whole.

Visual representation and interpretation

notation : Composite associations are shown as solid lines with black diamonds at the composite ends. This diamond represents the ‘whole’ and may or may not have arrowheads at the ends of the parts. An arrowhead indicates that the connection is a one-way reference; an absence of an arrowhead indicates a two-way reference.
Role Name : The role name given at each end indicates the specific role in the block. For example, in a car model, ‘engine’ might be the role name of the engine block.

Multiplicity at the composite end

Upper limit : The upper limit of multiplicity at the end of a complex is usually 1, meaning that a part can belong to only one complex structure at the same time. This is important to maintain system integrity and clarify the location and role of each part within a complex system.
Lower bound : If the lower bound is 0, the part can be removed from the composite structure as needed; if the lower bound is 1, the portion must always be associated with the composite structure. This is used to determine the essentiality of the part.

Multiplicity at the ends of parts

The multiplicity at the partial ends can be adjusted according to the requirements of the composite ends. This allows multiple parts to exist within a composite structure, increasing the scalability and flexibility of the system.

Application in embedded systems

Especially in complex systems such as embedded systems, in most cases the multiplicity of the complex ends is set to 1. This ensures that each part has a specific role and position within the system, contributing to increasing the stability and predictability of the system.

Implementation of Part Association in EA

Basic usage

Here’s how Part Association is implemented in EA:

Select a tool : Select Part Association from Toolbox.
Create a connection : Start from a partial end (Source) and drag to a composite end (Target) to make a connection. In this process, part refers to the components of the system and composite refers to the entire system.

Aggregation Properties Settings

Detailed properties of Part Association can be set in the Aggregation Properties window that appears by double-clicking the Connector. Here you can adjust various properties, including role name and multiplicity.

Example explanation: CAR-Wheel Association

This image shows a requirement Diagram in order to Understanding part property of block — This is a Block Definition Diagram drawn with Enterprise Architect. If you want to get more information about part property of block, this article may be helpful.

Reasons for Multiple Associations

In the example, the relationship between CAR and Wheel is implemented as four separate Part Associations. Each Association represents one wheel of CAR, and this approach emphasizes that each wheel plays an independent role.

Multiplicity settings : The multiplicity for each wheel was set to 1. This means that each wheel must necessarily be present in the CAR.

The importance of role names

Role names are given at the end of each Association part. This is used to specify that each wheel has a specific location or function. No role name is set at the end of the compound, because the reference to the entire vehicle is already clear.

Modeling Considerations

Selection of Part Compartment and Composition Association

Part Compartment : Generally used to concisely express the structural properties of a system. This method only highlights the presence and type of parts within the system.
Composition Association : Used when you want to express the structure of the system and the relationship between parts in more detail. This is advantageous when you want to reveal more clearly how the parts are connected and what their roles are.

Part Property with Internal Block Diagram

A block’s Internal Block Diagram (IBD) provides detailed information about the Part Properties that a specific block possesses. For example, let’s look at the IBD of the ‘CAR’ block defined in the Block Definition Diagram (BDD).

How to Create an IBD

Right-click on the ‘CAR’ block.
Select ‘New Child Diagram’ and then click ‘Internal Block Diagram’.

This will create a blank IBD canvas for the ‘CAR’ block. Now we need to add the part properties of the ‘CAR’ block to the IBD.

How to add part properties

Drag and Drop : Drag the part properties of the ‘CAR’ block directly from the Project Browser and place them on the IBD canvas.
Synchronize : Right-click on the IBD canvas and select ‘Synchronize Structural Elements’. This will automatically display all elements associated with the ‘CAR’ block in the IBD.

As shown in the image above, as many part properties as the number of related parts created in BDD appear in IBD. Each part property is displayed in the format ‘name : type [multiplicity]’.

Links between part properties

IBD can also reveal how each part’s properties interact. Part properties are primarily linked in two ways:

Connector : Indicates how two part properties are connected and interact.
Item Flow Relationship: Represents the type of material, energy, or data that flows between two part properties.

Now, select ‘Connector’ in ‘Toolbox’ to specify the interaction between the parts by connecting ‘Battery’ and ‘Motor’, and ‘Motor’ and each ‘Wheel’.

Adding Interaction to Connectors

IBD with Enterprise Architect allows you to not only represent connections between elements, but also specify the nature of their interactions. For example, let’s have ‘Battery’ and ‘Motor’ connected and add specific information about how these two elements interact.

Specify the name and type of the connector

To assign a name to the connector:

Select the appropriate connector.
In the ‘Properties’ window, open the ‘Connector’ tab and enter the name ‘BtoM’.

Initially the name ‘Hi-Voltage Connector’ was considered, but it was decided that this was more appropriate for the type. Therefore, we will specify ‘Hi-Voltage Connector’ as the connector type.

Defining connector types in BDD

To define the type of connector, first go back to BDD and define the relationship between ‘Battery’ and ‘Motor’ as a Reference Association named ‘Power Cable’. The relationship between ‘Motor’ and each ‘Wheel’ is also connected in the same way with the name ‘Torque Converter’.

Connector type assignment in IBD

Back in IBD, to specify the type for each connector:

Right-click each connector.
Select ‘Advanced’ → ‘Set Connector Type’ and then select ‘Reference Association’ created in BDD.

The connectors between the ‘Motor’ and each ‘Wheel’ are named ‘RFW’, ‘LFW’, ‘RRW’, and ‘LRW’, respectively. By clearly assigning names and types like this, you will have a clearer understanding of what each connector does.

Visualization of interactions between elements through IBD

Use of Item Flow

When using IBD in Enterprise Architect, you can go beyond simply showing how elements are connected; you can also express what information or resources are exchanged through each connection. For this purpose, we utilize ‘Item Flow’.

How to set up Item Flow

Select Item Flow from Toolbox.
Connect the battery and motor. At this time, the ‘Information Items Conveyed’ window opens and prompts you to select an information item.

This process requires clearly defining what flows through each connector. In most cases these elements are modeled as separate blocks.

Element modeling in BDD

Going back to the BDD, we create two blocks: ‘Current’ and ‘Torque’. These blocks represent electricity and torque respectively.

Integration of Connector and Item Flow

Returning to IBD, set the Item Flow for Battery and Motor as ‘Current’ blocks. Now you can see that Battery and Motor are connected to Connector and Item Flow at the same time.

Connector and Item Flow integration

Right-click the BtoM connector.
Select Advanced → Information Flows Realized and select ‘Current’ assigned as Item Flow.

Now the connector actually represents the path through which the item flows. This integration is represented visually by adding an arrow to the middle of the connector.

Realization of other connections

Item flow is assigned in the same way between the motor and each wheel, and this is realized. If you check the ‘Add Realizing Relationship’ button when setting up the Item Flow, you can add a new realized connector while maintaining the existing connector

In this post, we practiced the process of modeling the structure of a complex block, the interrelationships of each part, and the information flowing between elements using SysML’s bdd and ibd. This is a very important element in systems engineering, helping to clearly understand the functional interactions of a system through its structural elements.

In the next post, we will discuss ‘Reference Property’. This will enable the exploration of more complex interactions and system configurations.

Reference 1) Understanding Composite Block and Part Properties

In SysML modeling, “Composite Block” and “Part Properties” are two key concepts that represent the structure and composition of a system. These two concepts each provide a different level and perspective of the system, and they complement each other.

Composite Block

Definition : Composite block refers to a complex block with an internal structure. It may represent part or all of a system and may contain one or more subelements.
Role : It serves as a major component and integrates several sub-elements to implement the overall function of the system. For example, the composite block of a car may include the engine, wheels, body, etc.
Example usage : Used for modeling complex systems or subsystems, defining the overall structure, including the relationships and interactions with each sub-element.

Part Properties

Definition : A child element used within a Composite block. They are components of that block and perform specific functions.
Role : Represents a ‘part’ in a whole-part relationship and functions as a structural component within the Composite block. For example, a car’s engine or wheels can be viewed as Part properties.
Example usage : Specifies the internal structure and functionality of a parent block, and clarifies the role and function of specific components within the system.

Summary of differences

Scope and Application : Composite blocks represent broader systems or subsystems, while Part properties describe specific components within these parent blocks.
Structural Relationships : Composite blocks represent the complex structure of a system, while Part properties represent the details of specific parts.
Relevance : Part properties are generally defined within a Composite block and perform specific roles and functions within it.

Reference 2) Composition terminology summary

While performing SysML modeling, there is often confusion due to terms used slightly differently in various literature. In particular, terms related to “Composition” require accurate understanding as they contain important concepts. Here we summarize and explain some key terms.

Part Relationships

Definition : Part relationships represent structural connections between blocks, formally known as composite relationships or composite associations.
Purpose : This relationship indicates that one block contains another block. For example, if a car block contains an engine, wheels, etc., each of these elements has a part relationship with the car block.

Composition of Blocks

Definition : A set of blocks with part relationships is called a composition.
Example : When modeling the configuration of a car, all blocks that make up the car (engine, wheels, body, etc.) are connected through part relationships.

Activity of Composition

Definition : Construction refers to the process of integrating multiple parts or elements to create a complex system.
Importance : This course clearly shows how a composite block is made up of various parts and is important for understanding how each element is interrelated.

Importance of Terminology

Understanding and using these terms correctly is very important in SysML modeling. By understanding the specific meaning and scope of application of each term, you can build more accurate and effective system models.

If you are interested in other articles about the basic Knowledge of SysML with EA, please refer to the links below!

[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] #13. Understanding Reference Property of Block