[SysML] #19. Understanding Generalizations

In this blog post, we will take a closer look at Generalizations.

In the Block Definition Diagram (BDD), generalizations represent inheritance relationships between classifiers. This is similar to the inheritance structure between classes we commonly see in object-oriented programming. Inheritance allows another class (subclass) to inherit the characteristics and functions of one class (superclass).

The classifiers we will deal with in BDD include Blocks, Value Types, Interfaces, Interface Blocks, Signals, etc. The inheritance relationships between them allow us to model a systematic classification hierarchy of classifiers.

  1. Superclass and subclass : General classifiers are considered superclasses, and special classifiers are considered subclasses. A subclass can inherit the properties and functionality of the superclass while adding new properties and functionality.
  2. Reusability and extensibility : Generalization promotes reusability and extensibility of Classifiers. Common functionality is defined in the superclass, and subclasses inherit it and can extend or modify it as needed.
  3. Classification of structure and function : Generalizations can be applied to both structural properties (e.g. properties, ports) and behavioral functions (e.g. methods) of blocks. This allows you to organize your model and separate it into reusable components.
  4. Generalization relationship representation : A generalization relationship represents the relationship between a superclass and a subclass with a hollow triangle arrowhead and a line. This makes the direction of the relationship visually clear.
  5. Abstraction and Flexibility : Generalization provides flexibility in the system through abstraction. A superclass defines more general functionality, which subclasses can then inherit and extend as needed.
  6. Replaceability and Maintainability : Generalizations provide the flexibility to easily replace or add subclasses within the system. This significantly improves the maintainability and scalability of the system.

To help you understand, let me give you an example. Suppose we model Car as a superclass and Electric Car and Hybrid Car as subclasses. Here, the Car block defines general part properties such as wheels and engine type, as well as functions such as driving and stopping. The Electric Vehicle and Hybrid Vehicle subclasses inherit these general characteristics and add special features, such as electric charging or the combined use of fuel and electricity.

This modeling approach helps organize the various parts of the system systematically and creates a reusable and extensible structure. Generalization allows system designers to develop cleaner, more manageable models and reduces the effort required to maintain and extend the system.

Generalization is an essential tool for efficiently modeling complex systems and clearly defining interactions between components.

Inheritance and redefinition of Structural Features of Classifier:

  • Different blocks (classes) of a classification have differences in structural features, and subclasses provide additional features that are not present in the superclass.
  • Redefining a feature in a subclass is done to change or override an existing feature. This is to use new or changed features without using redefined features.
  • Overriding can include limiting the multiplicity of a feature, adding or changing defaults, providing a new or changed distribution, changing the feature type to a more restricted type, etc.
  • The redefinition process is documented using specific keywords and curly brackets.

Inheritance and redefinition of Classifier Behavioral Features:

  • Blocks and Interfaces Just as the structural features of blocks can be organized into classification layers, the behavioral features of blocks can also be processed.
  • Generic services are described as operations or services at an abstract level, while more specific services are described in specialized blocks.
  • The behavioral characteristics of the superclass can be redefined in the subclass, which allows the signature of the service to be modified.

Multiple Inheritance in Classifier

  • Refers to a situation where a subclass may contain functionality from multiple superclasses. This means that certain subclasses can be grouped into several additional classifications.

Generalization set of Classifier

  • A mechanism for grouping subclasses of a particular classification. It is used to describe how instances of a superclass can be related to instances of its subclass.
  • A generalization set has coverage and redundancy properties.
    • Coverage property : Indicates whether all instances of the superclass are members of the generalization set, with values of ‘complete’ or ‘incomplete’.
    • Overlapping property : Indicates whether an instance of a superclass can be an instance of one or more subclasses in the generalization, with values of ‘disjoint’ or ‘overlapping’.
  • Notation
    • Generalization sets are indicated by a dotted line, with the name of the generalization set and the values of the overlap and coverage properties in curly brackets.
    • Alternatively, in a tree-like generalization notation, the set of generalizations can be represented with a triangle symbol located near the root.

To model EA the generalization relationship between classifiers, we will use the example mentioned above with a slight modification.

“Suppose we model Car as a superclass and Electric Car and Internal Combustion Engine Car as subclasses. Here, the Car block defines general part properties such as wheels and engine type, as well as functions such as driving and stopping. The Electric Vehicle and Internal Combustion Engine Vehicle subclasses inherit these general characteristics and add special features such as electric charging or fuel usage.”

Create a new project and create a bdd called CAR. Then, a block called CAR is created on bdd. To simplify this example, we will only consider the Power Generator, Energy Storage, and Energy Source for propulsion of the car.

Add the Power Generator and Energy Storage blocks and assign them as part properties of the CAR Block. And Energy Source connects to CAR and Reference Association.

To display the Energy Source block in the references section of the CAR Block, create the ibd of the CAR Block and then click Synchronize Structural Elements to create reference properties on the ibd. For reference, you must specify a role in the reference association for the reference properties to appear on IBD.

Now let’s add behavioral characteristics (Classifier Behavior, Operation, Reception). Create Initialize Activity by creating an Activity Diagram using CAR’s Internal Diagram. (Right-click on the CAR block → New Child Diagram → Activity → with Activity Diagram). And assign Initialize Activity to Classifier Behavior in the Properties window.

Operation is created in CAR’s Features window. Since this example is for generalization practice, only the name of the Operation will be entered. It creates an operation called Re-Energy.

Lastly, for Reception, create a signal called Acceleration and assign it to Reception of CAR. (Reception can also be assigned in the Features window.)

The completed CAR block is shown below.

image 193

Now, create a bdd called CAR Types to create E(Electric)-CAR and ICE (Internal Combustion Engine)-CAR blocks, which are car types that inherit the CAR block.

Load the CAR block using Link on CAR Types bdd and connect it to E-CAR and ICE CAR in a generalization relationship. The connection is from Sub Class (i.e. block to be inherited) to Super Class (i.e. block to be inherited).

When you connect a generalization relationship, the Overrides & Implementations window appears, listing the operations that CAR has. And the description window asks you to choose between operations/interfaces.

In other words, if there is something to override or implement in the Sub Class among the Operations or Interfaces of the Super Class, you can select it in the corresponding window. First of all, there is nothing to Override or Implement in our example, so we will move on without checking anything.

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

After completing the Generalization connection, you will get the bdd above. However, I would like to display the inherited properties in the internal compartment of the E-CAR and ICE-CAR Block.

First, select E-CAR and click the Features window → Parts/Properties tab to view the Part Properties inherited from the CAR block. Because the super class CAR Block did not specify a name, there are Power Generator and Energy Storage named and Energy Source named ES.

If you select all, Power Generator, Energy Storage part, and Energy Source are created in the namespace compartment. If you click on each and delete them with the del key, they will be displayed neatly in the properties section and reference section.

image 195

Now let’s also display the inherited Behavior Feature. Right-click the E-CAR Block → Click Compartment Visibility. This will open a window of the same name, where you can set what to display in the Block section.

image 196

The parts that start with Inherited in the show Element Compartments section are inherited properties. Select Inherited Operation, Receptions (I don’t know why, but Receptions does not have Inherited Receptions) and press the OK button.

As you can see from the E-CAR section of bdd below, Operation and Reception are indicated in the form of ::Type to indicate which block they are inherited from. ICE-CAR also works the same way.

image 197

Now let’s model the subclass block in more detail. Energy Storage, Power Generator, and Energy Source also set inheritance relationships as shown in the following figure.

image 199

Then go back to CAR Types bdd and click E-CAR Block. In the Feature window → Parts/Properties tab, select the Type of Power Generator… Click the button to change it to Motor. Then Power Generator changes to Motor. Since Motor is a subclass of Power Generator, there is no grammatical problem even if Power Generator is changed to Motor. Change to Energy Storage → Battery, Energy Source → Charge.

For ICE-CAR, change to Power Generator → Engine, Energy Storage → Fuel Tank, Energy Source → Gas. The completed bdd is as follows.

image 200

Now, at the end of this post, we will set up the generalization set of the classifier. First, create a block that will act as a classifier to classify into a generalization set. Create a block called CAR_Type on bdd.

Then select Generalization Relationships between CAR ↔ E-CAR and right-click → Advanced → Generalization Set → New. In the Generalization set window, select Car Type for Name and the CAR Type block you created for Power Type. And check Is Member for ICE-CAR and E-CAR.
A classifier’s generalization set establishes its coverage and overlap.

  • Coverage property: Indicates whether all instances of the superclass are members of the generalization set, with values of ‘complete’ or ‘incomplete’. If you check Is Covering in the Generalization Set window, it will be set to complete, and if you do not check it, it will be set to incomplete.
  • Overlapping property: Indicates whether an instance of a superclass can be an instance of one or more subclasses in the generalization, with values of ‘disjoint’ or ‘overlapping’. If you check Is Disjoint in the Generalization Set window, it will be set to disjoint, and if you don’t check it, it will be set to overlapping.

In our model, instances of CAR are not necessarily E-CAR or ICE-CAR. (For example, there is Hybrid CAR.) Therefore, the scope of application is incomplete. And since CAR cannot be both E-CAR and ICE-CAR, the redundant attribute is disjoint.

Check is Disjoint and click Ok. The completed bdd is as follows.

image 201

[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] #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