[SysML] #13. Understanding Reference Property of Block

쉬운 목차

Understanding Reference Property of Block

In this blog post, we will take a closer look at reference 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.

Definition and characteristics of reference properties

Location and expression of reference properties

Reference properties are placed in the reference compartment of a block, indicating that a block instance can reference other block instances. This section begins with the keyword ‘reference’, and reference properties are indicated by specifying the block name and type.

The importance of ‘need’ relationships

Unlike part properties, reference properties are described as ‘required’ rather than ‘owned’. This means that the end of the reference can be maintained even if the referencing block is removed, increasing the flexibility of the system.

Constraints at end of reference

Reference properties can be used by multiple blocks referencing the same instance, without restrictions. This is useful when the reference attribute refers to a common resource or service within the system.

Use cases for reference properties

The need for interaction

Blocks with reference properties are primarily used when interaction with external structures is required. For example, when a sensor block requires data from another device, this connection is modeled through reference properties.

Addition of logical layers

Reference properties are used to reference blocks in other configuration layers, providing an additional logical perspective beyond the whole-part hierarchy of the system. This shows that systems can have different levels of interaction and dependency.

Role in Internal Block Diagram

The purpose of reference properties is primarily represented in the Internal Block Diagram (IDB). IDB is used to comprehensively model the items and logical relationships that a particular block must store or manage.

Base types and components of reference properties

Form

Reference properties are typically expressed in the Reference Compartment of a block in the following format:

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

Reference Name : This is a name that can be freely determined depending on the object being referred to. This name is used to identify the reference property and serves to clarify the reference relationship within the model.
Type : Type refers to the type of block or actor that the reference property represents. It refers to another block or actor defined within the system, and specifies what type of element the reference property is associated with.
Multiplicity : Multiplicity limits the number of instances a reference property can represent. This can be expressed using a single integer, a range of integers, or a specific condition (e.g. 0..*, 1..3, etc.). Multiplicity indicates how many instances a referencing block or actor can have at one time, which provides important information for designing the operation and constraints of the system.

Definition and characteristics of reference and shared associations

Purpose and Expression

Reference associations represent interactions or necessary relationships between blocks and are used to express connections to specific structures. This association is typically represented by a solid line between two blocks, and unlike compound associations, black diamonds are not used.

A shared association uses a white diamond at one end to indicate a relationship between a part and a whole, but does not imply ownership. This is sometimes expressed as distinct from a reference association in tools such as EA.

Direction of association

Reference properties on one end : If a reference association has reference properties on only one end, an open arrowhead indicates the direction toward which type is being referenced.
Bidirectional reference : If both ends have the reference attribute, there is no arrowhead to indicate a bidirectional reference.

Multiplicity and role names

The multiplicity setting is located at the end of a reference association and indicates how many instances the connected block can have. Role names clearly describe the roles between associated blocks and are used to specifically define the role of each linked block.

The importance of association names

The association name can optionally appear in the middle of the association and is used to describe the type of connection between the two blocks. This name plays an important role in clearly communicating the purpose of the association during the documentation of your system.

Additional Explanation of Reference Associations

A reference association represents a loose relationship between two model elements. This relationship is represented by a solid line without diamonds, indicating that one element can reference another element. For example, a reference association between ‘Driver’ and ‘Car’ shows that ‘Driver’ can refer to ‘Car’, which is usually highlighted by an arrow indicating one-way access. This association means that ‘Driver’ has access to ‘Car”s data, but does not own it.

Description of Shared Association

Shared Association is a weaker form of Composite Association, indicating a relationship between a whole and its parts, but without explicit ownership. This is represented by white diamonds and solid lines, and can be seen between elements such as ‘Car’, ‘Gas’, ‘Tire’, and ‘Black Box Camera’. These elements are used by ‘Car’, but are not limited to parts of ‘Car’, and parts may remain even if the entire element is deleted.

Distinction from Composite Association

Composite Association : This is the strongest association, meaning that when the whole is deleted, the parts are also deleted. Represented by a black diamond, the whole and the parts are inseparable.
Shared Association : This represents weaker ownership than Composite Association, and parts may remain even if the whole is deleted. Represented by a white diamond, the part is included in the whole, but is not required to do so.
Reference Association : Since there is no ownership, it simply indicates a reference or access. No black or white diamonds are used, mainly to indicate that there is some interaction.

Reference Property with Internal Block Diagram

Reference and Shared Property in Internal Block Diagram are used similarly to Part Property. However, the visual difference is that it is displayed as a dotted box symbol rather than a solid line.

In this post, I will introduce how to add a Reference Property by expanding the Part Property example of the CAR model that I wrote previously.

Example of additional Reference Property: Charger

Let’s model the battery charging process by adding a charger to the CAR model. The Charger is not directly included in the CAR block, but performs the charging function through interaction with the Battery within the CAR. In this case, a reference association is used to connect the battery and charger.

Since Charger and CAR always interact in a 1:1 relationship, the multiplicity of the connection is set to 1 on both ends. Through this connection, the Charger supplies current to the Battery, and the Battery informs the Charger of its current status. This connection was named ‘Charging Cable’.

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

Now, let’s look at how to create Battery’s Internal Block Diagram (IBD) from CAR’s Block Definition Diagram (BDD) and add Reference Property through the process of synchronizing structural elements.

Battery IBD creation and reference property synchronization

Select Battery Block from BDD : Select Battery Block from BDD of CAR.
Create IBD : With Battery Block selected, create an IBD. This work is a process to visualize and design the internal structure of the Battery Block in detail.
Click on Synchronize Structural Elements : Select the ‘Synchronize Structural Elements’ option in Battery’s IBD environment. Through this, connections defined in BDD are synchronized to IBD and actual structural elements are created.
Reference Property Creation : The Reference Association established between the Battery and Charger in the BDD indicates that the Battery Block is connected to the Charger in the model. Now we need to create an instance of the actual Charger in IBD.
Check Project Browser : In the Project Browser, you can see that a new Reference Property named ‘Charger’ has been created under Battery Block.
Drag and drop to CAR’s IBD : Drag and drop the created Charger Reference Property to CAR’s IBD. This process visually represents the external Charger Block connected to the Battery within the CAR and clearly models the interaction between the two blocks.

I would like to explain the process of modeling interactions. Below are step-by-step instructions for modeling the interaction.

Modeling interactions between Battery and Charger

1. To define an Item

Battery sends battery status data to Charger.
Charger supplies current to Battery.

2. Create Battery Status Data Bloc

Create a Battery Status Data Block similar to the Current Block created in the Part Property exercise.

3. To connect Item Flow in IBD

Connect Item Flow from Battery to Charger in IBD.
At this time, select Battery Status Data in the Information Item Conveyed window, check the “Add Realizing Relationship” option and click OK.

4. To set up Item Flow from Charger to Battery

In the Information Item Conveyed window, select Current, check the “Add Realizing Relationship” option and click OK.

5. To set the connector type

To specify the type of each connector, right-click on the connector.
Select Advanced → Set Connector Type to set the type of each connector to Association between Battery Block and Charger Block in BDD.

Shared Property and Internal Block Diagram

Shared Property is generally treated similarly to Part Property in IBD. However, because it does not directly belong to the entire element, it is displayed as a Reference Property. Additionally, Shared Property has the concept of a part belonging to the whole, so in BDD, unlike Reference Property, it has an association with a block that represents the whole.

Let’s explain this concept with an example. Think of it like a doll that you place on your car dashboard. This doll should always be on the car dashboard (i.e. it’s included with the car), but it can also be placed on my work desk after the car is disposed of. However, it cannot be in two places (the car and my desk) at the same time.

Let’s apply this example to the CAR model. First, create a block called “Snoopy” in BDD and then connect it with the CAR block through Shared Association. At this time, drag from part to whole to connect. And if you click on the “Synchronize Structural Elements” button in IBD, it will show up in IBD. However, since it does not interact with any properties currently owned by the CAR block, no further action is required.

Please note that because Snoopy and Charger are the same Reference Property, it is difficult to distinguish between Shared Association and Reference Association in IBD. BDD and IBD are complementary and should be used together to well express the perspective being modeled.

I hope this post helped you understand the structural elements of SysML such as BDD, IBD, Reference Property, Reference Association, and Shared Association. In the next post, we will cover Value Property.

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] #12. Understanding Part Property of Block