Change propagation analysis for system modeling using semantic web technology

Change propagation analysis for system modeling using semantic web technology Change propagation analysis for system modeling using semantic web technology Change propagation analysis for system modeling using semantic web technology Change propagation analysis for system modeling using semantic web technology Change propagation analysis for system modeling using semantic web technology Change propagation analysis for system modeling using semantic web technology

Contents lists available atScienceDirect

Advanced Engineering Informatics journal homepage:www.elsevier.com/locate/aei

Full length article

Change propagation analysis for system modeling using Semantic Web

technology

Haoqi Wanga,⁎, Vincent Thomsonb, Chengtong Tanga

a School of Mechanical Engineering, Beijing Institute of Technology, China

b Department of Mechanical Engineering, McGill University, Canada

A R T I C L E I N F O

Keywords:

Model-based systems engineering

System modeling language

Engineering change management

Change propagation analysis

Ontology

Semantic Web technology

A B S T R A C T

Change propagation potentially affects many aspects of a SysML-based system model during the iterative process

of Model-Based Systems Engineering (MBSE) However, few authors have addressed the implication of en-gineering change and its impact To address having a successful change process, this article analyzes and ex-plicitly represents different scenarios of how a system model is changed from a formal perspective, i.e., how a system model should be changed, and how model elements should be added, deleted or modified in response to design changes A workflow is introduced to guide the change process taking change propagation into account Second, change impact relationships among requirements, behaviors, and structures of the system model are formalized by an ontology to make the semantics both human-understandable and machine-readable Reasoning rules are defined as well in order to improve automation of the change process Finally, an experiment using a water distiller system showed that the identification of change impact information could help designers complete the change in less time and with higher quality

1 Introduction

Systems modeling of contemporary products using model-based

systems engineering (MBSE) is an iterative process involving

re-presentations of multiple views, e.g., requirements, behaviors, and

structures The systems modeling language (SysML) is a key enabler in

MBSE approaches for creating a system model[1] During the modeling

process, system design evolves through many modifications until it is

feasible Accordingly, the SysML-based system model, which produces

the primary artifacts from a system design, has to be modified

fre-quently A single design change may lead to unexpected effects on other

model elements For example, an added requirement to the original

system design of a water distiller causes changes to the distiller

beha-vior, decomposition structure and internal structure that are tedious to

make [2] So, Engineering Change Management (ECM) of the system

model plays a pivotal role for a successful implementation of MBSE

As one of the ECM methods, the SysML-based methodology can

evaluate change situations arising from system design by representing

requirements, behaviors, structures and their relationships in a

con-sistent way[3] However, few authors have addressed the implication

of engineering change and its impact or the implication of different

approaches to design implementation, such as, technology,

modular-ization and make-or-buy [4] Although allocation relationships in

SysML are able to enhance the traceability of a system model[5], they are insufficient for specifically describing how change is propagated to impacted model artifacts In practice, it is always time consuming for designers to identify and change impacted model elements manually One reason is that requirements and scenarios are not always fully

defined, and thus, design changes require considerable analysis in order

to decide upon feasible approaches As a consequence, in order to keep the system model compatible with design changes, designers have to spend most of their time finding which model elements should be changed given how changes are propagated throughout the design and which types of changes should be executed for specific model elements For instance, in order to change the initial system design of a water distiller, more than 60 model elements were required to be added, deleted or modified[2]

Accordingly, limited to a formal perspective, not an engineering perspective where changes to detailed design parameters, such as the dimension, weight, and material of components, are taken into account, this paper addresses an approach that should be used for MBSE mod-eling when reasoning about change propagation To determine this approach we focus on three questions:

(1) How can the approach help designers to understand what needs to

be changed in the systems modeling process?

https://doi.org/10.1016/j.aei.2017.11.004

Received 4 May 2017; Received in revised form 25 November 2017; Accepted 29 November 2017

⁎ Corresponding author.

E-mail addresses: Haoqi.wang@mail.mcgill.ca (H Wang), vince.thomson@mcgill.ca (V Thomson), tangcht@bit.edu.cn (C Tang).

1474-0346/ © 2017 Elsevier Ltd All rights reserved.

T

(2) If a change happens in a specific SysML diagram, how can the

ap-proach help designers know how other related diagrams need to be

changed?

(3) What procedures can be automated when modifying system

en-gineering models due to change propagation?

In order to answer these questions, first, this paper categorizes

different scenarios of the SysML modeling change process into three

subclasses and establishes a change propagation model Second, the

Web Ontology Language (OWL) is used to formalize the change

pro-pagation information, based on which reasoning rules are defined to

help designers to understand which SysML diagrams and model

ele-ments need to be changed, and then, guides them through the tedious

process of manually changing SysML models Third, possible

automa-tion of the process is investigated

2 Research background

2.1 Previous work about change impact analysis for the system model

Existing research on the impact of change on the system model in

MBSE can be divided into two classifications One is comprehensive

research on using the analytic capability of matrix-based

representa-tions The second is research on predicting the change propagation risk

by checking the inconsistency and incompatibility of the changed

system model

Thefirst classification focuses on establishing a Design Structure

Matrix (DSM) or a Multiple Domain Matrix based on SysML diagrams,

and then, using these matrixes to predict the impact of change[6–12]

Matrix-based representations offer magnificent analytic criteria to

achieve system understanding [10] Clarkson et al.[6] developed a

Change Propagation Method using numeric DSMs for the first time

Hamraz et al [7]extended the Change Propagation Method by

in-troducing Function-Behavior-Structure models Hamraz et al.[8]

fur-ther detailed the ontology of the Function-Behavior-Structure linkage

method to provide a uniform framework for developing models

Waldman and Sangal[9]were thefirst to construct a DSM that unites

the various views of SysML models Maisenbacher et al.[10]illustrated

the translation of SysML diagrams with network structures to their

matrix representation as a DSM or Multiple Domain Matrix, so as to

identify indirect dependencies in a system model Nonsiri et al.[11]

proposed a method for identifying the propagation path of changed

requirements by integrating a SysML model with a higher order DSM

Fei et al [12] developed a matrix-based method to analyze change

propagation between components of a product based on functional and

structural SysML models

The second classification mainly studies checking the inconsistency

and incompatibility of changed system designs to predict change

pro-pagation risk[13–16] By considering mechanical, software and

elec-trical⧹electronic incompatibility of changed mechatronic systems, an

interdisciplinary SysML-based approach, called SysML4Mechatronics,

for analyzing change influences was proposed by Kernschmidt and

Vogel-Heuser[13] Feldmann et al.[14]formalized the incompatible

information of the change influences of mechatronic manufacturing

systems by integrating systems modeling with semantic technologies

Kernschmidt et al [15] extended SysML-based incompatibility

checking to the entire system lifecycle Nejati et al.[16]suggested how

to automaticallyfind out the impact of changes to requirements based

on a system design expressed by SysML models through computing

reachability through inter-block dataflow and intra-block data as well

as controlflow dependencies

However, as listed inTable 1, change impact analysis of a

SysML-based system model, only a few of the works have investigated the

change process itself when an engineering change happens, i.e., how

the design or system model should be modified, and which model

elements should be added or deleted in response to design changes

Two such studies partially involve change implementation[17,18] Lin

et al.[17]proposed a workflow to combine change request manage-ment with model-driven engineering for industrial automation soft-ware In the technical review phase, affected model elements of the change requirements were identified, and a change solution was pro-posed In the impact analysis phase, processes that guide designers to change SysML models were provided However, several limitations still exist First, the method for identifying impacted model elements is only available for restricted situations where the impact of complex changes

to requirements, behaviors, and structures cannot be fully represented

by SysML cross-cutting relationships alone In SysML, a cross-cutting relationship is a kind of mapping relationship which can be established between any two model elements There are two types of mapping re-lationships,① the intra-domain relationships, i.e., the links between elements within a given domain, and② the inter-domain relationships, i.e., the links between elements across two domains[5] A cross-cutting relationship is the latter, i.e., an inter-domain relationship Second, besides the existing system model, two more SysML-based models should be created to represent impacted model elements and the cor-responding change solution For a system model with large SysML diagrams, this is obviously time-consuming Jiang et al [18] estab-lished a function-behavior-structure model of product design history to predict the effect of function change on the final product structures More importantly, what should be changed during the system design is clearly defined However, in contrast with SysML, the function-beha-vior-structure model covers only partial information of a system model For example, for the structure layer of the function-behavior-structure model, only assembly relationships are described The items, such as signals, energy or data, whichflow across different components, are not specified

Based on the above analysis, this paper emphasizes the need to improve the SysML model change process itself For enabling designers

to understand which SysML diagrams and model elements should be changed, scenarios for each change type and their change propagation information should be specified and formalized

2.2 Semantic Web technology

With regard to the many information representation technologies, Semantic Web technology [19] is being accepted by an increasing number of industries due to its strong semantic and logic expression capabilities Semantic Web technology provides the foundation for the representation of an ontology, which defines specific vocabularies of domain concepts and their semantic relationships[20] According to Zhang et al.[23],“the World Wide Web Consortium has contributed much towards standardizing the specification necessary for Semantic Web technology” by introducing the Resource Description Framework (RDF) and the RDF Schema[21] In order to enhance knowledge re-presentation, the World Wide Web Consortiumfinalized the OWL[22]

by extending the expressive power of the Resource Description Fra-mework and the RDF Schema However, there are many semantic re-lations that cannot be specified explicitly by the OWL ontology

Table 1 Change impact analysis of a SysML-based system model.

Approach In change stage

Impact analysis

Implementation

Matrix-based approach [9–12] Yes No Inconsistency and incompatibility contrast

approach [13–16]

Yes No Analyzing the change workflow [17] Yes Partially done Specifying the change situations of system

functions, behaviors, and structures [18]

Yes Partially done

especially in the reasoning process[23] The Semantic Web Rule

Lan-guage (SWRL)[24]is an OWL-based rule language and it enables users

to write rules in regard to OWL concepts so as to give more

influen-tial referring capabilities than OWL alone

In this paper, OWL is used to formalize concept elements and their

semantic relationships for change propagation information SWRL rules

are defined to determine impacted model elements that should be

changed

3 Approach

Fig 1 describes an overview of a general system model change

process Different kinds of operations are classified in four rounded

rectangles with dotted lines From left to right,first, data from different

views, such as functional requirements, behaviors and structures are

put into a repository in order to manage the system model Second,

different SysML diagrams, like the Requirement Diagram, Activity

Diagram, Block Definition Diagram (BDD) and Internal Block Diagram

(IBD), are applied to represent the model Third, if the current design

does not perform as expected, for example, a new requirement is

needed or an existing component should be replaced, the system model

is changed as necessary to develop a feasible solution For example,

with the change of some functional requirements, impacted behaviors

and structures in the system model are changed After the design

change process, the result is a set of updated SysML diagrams Fourth,

during the change process, how the modeling elements are impacted by

the original change is identified in specific diagrams and how to

im-plement the changes is the set of objectives (shaded inFig 1) for the

proposed approach For example, when new actions are added to an

activity diagram for realizing a new functional requirement, impacted

elements such as actions, output pins, input pins and objectflows that

need to be deleted, added or modified accordingly in the diagram are

identified automatically The proposed approach is expected to infer

how the system model should be changed, and which model elements should be added, deleted or modified in response to design changes, such that the designer is guided to change the system model without needing to search for impacted SysML models manually

The proposed approach integrates system models with Semantic Web technologies as shown inFig 2 First, general change scenarios of the SysML model are analyzed and categorized, and a process for changing the system model according to change propagation is estab-lished Second, the change propagation information is formalized using the OWL ontology Third, by using predefined SWRL rules, impacted SysML elements can be identified

3.1 General change scenarios of SysML modeling What deserves illustration before analyzing different change sce-narios is that changes in this paper are regarded as indispensable ad-justments implemented on SysML diagrams in order to satisfy design change demands rather than changes that occur due to unexpected errors such as using a satisfy relationship to connect a requirement with its derived requirement or creating an output pin for an inputflow

In thefirst place, based on design change demands, model artifacts that should be changed directly are specified Changes implemented on any one of these are categorized into three subclasses: addition, dele-tion or modificadele-tion

Addition The act of adding a model artifact means creating, drawing and putting it into a changed diagram, in which case if the new artifact has relationships with other artifacts, more changes are required For instance, when a new block is created and added to a BDD as a part of

an assembly, a composition association should be added as well be-tween the new block and the block representing the assembly

As depicted inFig 3, one of four scenarios occurs when a new model artifact is added Because SysML is a graphical representation language, the added artifact is either a node, e.g., a function, a

Repository

System

structures

System

behaviors

System

function

requirements

Requirement Diagram

IBD

Activity Diagram

Requirement Diagram

Original changed FR

Changed Requirement Diagram

Analyze and change the Requirement Diagram

Changed Activity Diagram

Impacted actions

Analyze and change the Activity Diagram

Changed IBD & BDD

Impacted blocks

Analyze and change the IBD & BDD

Reasoned impacted elements

Impacted blocks, ports, interfaces, connectors, partAssociation relationships and their change types are identified

Impacted actions, input pins, output pins, item flows and their change types are identified

Impacted function requirements and their change types are identified

Satisfied by

Allocated to

A i i

BDD IB

Trace to

Fig 1 System model change process showing the proposed approach.

requirement or a component, or an edge, e.g., an hierarchical

re-lationship between two components that bridges two nodes So, for

simplicity, only two nodes and one edge are used to represent the

ori-ginal diagram Diagrams with more model artifacts can be analyzed by

combing the four scenarios

As for the first scenario inFig 3, an independent node is added

having no relationship with other artifacts For instance, a shutdown

action indicating the termination of all of the actions of a particular

activity is a kind of independent node in the activity diagram In the

second scenario, an edge is added for linking two nodes A new node

with a corresponding edge is added in the third change scenario In the

last scenario, a new node is inserted between two nodes when two new

edges are added and the original edge is deleted In addition, the

complexity of the four addition scenarios increases from thefirst to the

last due to the growing number of impacted artifacts

Deletion The act of deleting a model artifact means removing a node

or edge in a specific diagram When a node is deleted, edges connecting the node with other nodes should also be deleted However, an edge can

be deleted without changing related nodes

Fig 4exhibits three kinds of deletion actions An edge is deleted alone in thefirst scenario A node is deleted by removing its related edge in the second scenario In the third scenario, a node is deleted followed by removing two edges, by which the deleted node is con-nected to the other two nodes

Modification The rearrangement and property change of model ar-tifacts are taken into account as two sub-categories of modification actions: the layout modification and the property modification Fig 5shows layout modifications where a node is moved to a new place in scenario 1 and where the edge of the modified node is further rearranged in scenario 2 Modifying the property of a node or edge is a property modification, as depicted in scenarios 3 and 4 inFig 5 For example, items thatflow between two blocks can be modified to change material requirements The change can be in part properties to increase performance, or in the service of a standard port to update a software program

If a new modeling element is added into a SysML diagram, the layout of the diagram has to be changed For example, the location and size of a new block, which represents a new component, should be modified to ameliorate the readability of the changed diagram

Section 3.1 and 3.2

General change scenarios of the SysML model

are analyzed.

A process for changing the system model

considering change propagation is established

Section 3.3

S ti 3 3

Formal representation of the change

propagation model is defined using the OWL

ontology

Section 3.4

Rules for inferring impacted SysML elements

are defined.

Fig 2 Integrate MBSE approach with Semantic Web technology to identify impacted

SysML elements.

1

3

4 2

Unchanged node Added node Unchanged edge Added edge

Complexity

Fig 3 Addition of a new model artifact.

2

3 1

Unchanged node Deleted node Unchanged edge Deleted edge

×

×

×

×

Fig 4 Deletion of a model artifact.

1

2

3

4

Unchanged node Modified node (property)

Modified edge (layout) Unchanged edge

( Modified node (layout)

Modified edge (property)

Fig 5 Modification of a model artifact.

3.2 Process for changing the system model with change propagation

After specifying different scenarios of how the system model is

changed in MBSE, the following section illustrates how a change affects

other model artifacts, and then, establishes a workflow to guide the

change process taking change propagation into account

An original design change is said to propagate when it is reflected in

different model artifacts For example, a deleted system functional

re-quirement can result in the deletion of corresponding artifacts that

represent system behaviors or structures Change propagation can be

recognized by combining the cross-cutting relationships of SysML with

the different change scenarios in Section3.1

In this paper, a SysML requirement diagram is used for expressing

system requirements and their relationships; system behavior is

mod-eled by a SysML activity diagram; a SysML BDD and an IBD are used for

capturing system structure

In different SysML diagrams, the nodes and edges that need to be

changed are not regarded in the same way Partial SysML model

ele-ments are provided in Table 2in a requirement diagram where

re-quirements are considered as nodes that are related by containment

links and drive links In an activity diagram, actions are defined as

nodes, which are connected byflows between their input and output

pins In a BDD, nodes are defined as blocks related by part associations

and generalization links In an IBD, nodes are items that are exchanged

between block ports by connectors

In addition, cross-cutting relationships can document mappings

among SysML diagrams[2], and those used in the change process of the

system model are displayed in Fig 6 A functional requirement in a

requirement diagram is satisfied by a block in a BDD and is traced to an

activity or action in an activity diagram Actions are allocated to a block

in a BDD that executes these actions A pin and connector of an action

in an activity diagram are allocated to a port and a connector of a block

in an IBD A block in a BDD has a dependency relationship with a block

in an IBD

A process is illustrated inFig 7that describes how to change dif-ferent SysML diagrams in general, according to pre-specified change scenarios when changes are propagated First, the change type is de-termined Second, the change scenario is selected Third, according to the specific change type and scenario, nodes and edges in the SysML diagram are added, deleted or modified Last, if a change is completed, impacted model artifacts in another SysML diagram are identified through cross-cutting relationships; else, a new round of change pro-cedures for changing the same diagram begins again

One of the dominant steps in the SysML diagram change process is the identification of impacted model artifacts in other SysML diagrams using cross-cutting relationships, which is shown in the bottom, shaded textbox inFig 7 For instance, if a requirement in a specific require-ment diagram is deleted, its impacted actions, blocks and related pins, flows, connectors, etc are identified by the ≪trace≫, ≪allocate≫,

≪satisfy≫ and ≪depend≫ relationships in the activity diagram, and the corresponding IBD and BDD are identified and removed as well Fig 8 exhibits this identification and removal process First, by the trace relationship, the activity and its pin andflow in the corresponding activity diagram are identified and deleted Then, based on three allo-cation relationships, the identified block and part association in the BDD diagram, and the block, port, and connector in the IBD are deleted

In addition, impacted model artifacts and modification scenarios can be identified in a similar way

3.3 Ontology for change propagation information Based on the specification of change scenarios that use a system model and a change process for documenting change propagation, this section formalizes the change propagation information using the OWL ontology

3.3.1 Basic SysML-based system model ontology The basic concept elements of a SysML-based model and element semantic relationships are createdfirst SysML model artifacts include the SysMLDiagram, SysMLNode and SysMLEdge classes As shown in Fig 9, the elements are further categorized according to a SysML spe-cification For example, SysMLEdge that bridges two SysML nodes is classified into the IntraDiagramEdge and InterDiagramEdge classes The IntraDiagramEdge class means edges in the same diagram, whereas the InterDiagramEdge class stands for edges between two different kinds of diagrams BDD, IBD, ActivityDiagram, and RequiementDiagram are sub-classes of the SysMLDiagram

Table 2

SysML diagrams, nodes and edges used in a system model.

Diagram type Nodes Edges

Requirement diagrams Requirements Containment links, derive

links Activity diagrams Actions, pins,

parameters

Control flows, object flows BDDs Blocks Part associations,

generalization links IBDs Blocks, ports Connectors

Trace

Allocate

Depend

Allocate Allocate

Satisfy

Fig 6 Uses of cross-cutting relationships.

Besides hierarchical model artifacts, there are other semantic

re-lationships among the artifact concepts, like ‘‘hasRequirement”,

“hasBlock”, “allocate” and ‘‘satisfy”, etc According to Zhang et al

[23],”semantic relationships are usually defined as object properties of

the ontology by means of which retrieval and tracking from one artifact

to another artifact within a diagram or between two different diagrams

become possible.”Fig 10exhibits partial semantic relationships among

model artifacts

3.3.2 Change propagation information ontology

Basic SysML-based system model ontology provides the foundation

for the representation of change propagation information Concept

elements about SysML change process information and their semantic

relationships are described in this section

Changed SysML model artifacts are classified into the ChangedNode and ChangedEdge classes as described inFig 11 Instances of changed model elements can be existing SysML nodes and edges that are docu-mented in the basic SysML-based system model ontology They are associated with specific SysML diagrams by “hasChangedNode” and

“hasChangedEdge” object properties, and they are associated with changed nodes or edges by the“belongTo” property Furthermore, the

“propagateTo” object property associates a changed model artifact with the original artifact

Furthermore, attributes of the change propagation information on-tology are represented by data properties, which associate objects with

different data types Some of these attributes are illustrated inFig 12

Determine the change type

Determine the addition scenario deletion scenarioDetermine the

Determine the modification scenario

[type==addition] [type==modification]

[type==deletion]

Add an

independe

nt node

Add an edge

Add a node with an edge

Insert a node

Delete

an edge

Delete a node with

an edge

Delete a node with two edges

Modify the layout of a node

Modify a property of

a node

Modify the layout of

an edge

Modify a property of

an edge

Is the change compelte?

[No]

Identify impacted model artifacts in other SysML diagrams using cross-cutting relationships

[Yes] Change another

diagram

Fig 7 Change process of SysML diagrams.

Trace

Allocate

Depend

Allocate Allocate

Satisfy

×

×

×

×

Deleted nodes

Deleted edges

Fig 8 A deleted requirement and its propagation identification using cross-cutting relationships.

For example, the “hasAddScenario” data property connects a SysML

diagram with different additional scenarios as illustrated inFig 4by

the enumeration, {“add_1”, ”add_2”, “add_3”, “add_4”}; the

“isChan-gedNode” property of a node is “True” when the node in a specific

SysML diagram is changed, whereas the“isImpactedNode” property of

a node is “True” when the node should be changed due to change

propagation The data properties of are exhibited inTable 3

3.4 SWRL rules for inferring impacted model elements

The ontology defined above can provide the concept knowledge

model for change propagation information of the system model in

MBSE In this section, SWRL is used to define rules that can be added to

the inference engine for assisting the ontology to complete the

rea-soning and retrieval of change propagation information Compared to

research by Zhang et al [23], inverse relations, mutual exclusion

re-lations, domains and ranges are defined in the same way However,

Zhang et al [23]use OWL and SWRL to represent the semantics of

design rationale information, such as design issue, solution, argument

and artifact In contrast, this paper focuses on change of the

propaga-tion informapropaga-tion of SysML based system models, such as requirements,

behaviors, structures, changed modeling elements and impacted

mod-eling elements

First, according to Zhang et al.[23],“in addition to part of the

built-in OWL relations and properties, the semantics of the user-defined re-lations and properties need to be explicitly defined by axiom rules”, such as inverse, transitive and disjoint axioms For example, domains and ranges of classes and properties of the ontology are restricted

OWL: Thing

SysMLDiagram

SysMLNode

SysMLEdge

ActivityDiagram ActivityDiagram RequirementDiagram

BDD IBD

Block Pin

Action

A ti Requirement

InterDiagram

Edge

IntraDiagram Edge

AllocateEdge DependentEdge SatisfyEdge TraceEdge

Connector ContainmentLink ObjectFlow DriveLink Generalization PartAssociation owl: subClassOf

Fig 9 A partial SysML model artifacts hierarchy.

SysMLEdge

SysMLNode

SysMLDiagram

hasNode

hasEdge

Requirement

Diagram BDD

Block Requirement

Pin

hasRequirement

satisfy

hasPin

ObjectFlow hasObjectFlow

hasBlock

ActivityDiagram

Action hasAction

Connector

trace

IBD

hasConnector

allocate

partOf

contain owl: subClassOf

objectProperty

InterDiagramEdge

Port hasPort

allocate

Fig 10 Some semantic relationships among SysML model artifacts.

OWL: Thing

SysMLNode

ChangedEdge

owl: subClassOf

SysMLDiagram

hasChangedNode

hasChangedEdge

objectProperty

ChangedNode

SysMLEdge

propagateTo

propagateTo Action

Block

Pin Requirement

belongTo

Connector ObjectFlow

DriveLink PartAssociation

belongTo

belongTo belongTo belongTo

belongTo belongTo belongTo impactDiagram

Fig 11 Some changed SysML model artifacts and their semantic relationships.

SysMLDiagram

SysMLNode

SysMLEdge

Enumeration

Boolean

Boolean

Enumeration hasDeleteScenario

Enumeration hasModifyScenario

isChangedNode Boolean

isImpactedNode isChangedEdge

Boolean isImpactedEdge

Boolean

Boolean isChangedDiagram

isImpactedDiagram hasAddScenario

hasNode

hasEdge

owl: subClassOf objectProperty dataProperty datatype

Fig 12 Some attributes of changed SysML model artifacts.

Table 3 Data properties of the change propagation information ontology.

Data property Domain Range hasAddScenario SysMLDiagram {add_1, add_2, add_3, add_4}

hasDeleteScenario SysMLDiagram {delete_1, delete_2, delete_3}

hasModifyScenario SysMLDiagram {modify_1, modify_2, modify_3,

modify_4}

isChangedDiagram SysMLDiagram Boolean isImpactedDiagram SysMLDiagram Boolean isChangedNode SysMLNode Boolean isImpactedNode SysMLNode Boolean isChangedEdge SysMLEdge Boolean isImpactedNode SysMLEdge Boolean shouldBeAdded Boolean shouldBeDeleted Boolean shouldBeModified Boolean

“propagateTo” and “impactedBy” properties are used to represent the

semantic relationships when a change is propagated from a model

element to another model element where a model element is impacted

by a changed one So, the two object properties are mutually inverse

and can be defined as:

= propagateTo(? x,? y) impactedBy(? y,? x)

InterDiagramEdge and IntraDiagramEdge classes are distinct from

each other where a SysML edge crosses two diagrams or is within a

diagram, respectively Therefore, relationships between the two classes

can be defined as:

InterDiagramEdge(? x)

IntraDiagramEdge(? x) Φ

Second, according to existing relationships, new relationships are

able to be reasoned through a set of rules When certain conditions are

satisfied, a new relationship can be derived by automatic reference For

instance, the following shows some of the existing relationships:

•hasNode(? d,? n): The instance d of the SysMLDiagram class has an

instance n in the SysMLNode class;

•hasDeleteScenario(? d,“delete2”): The deletion scenario of the SysML

diagram d is“delete_2”

•isChangedNode(? n,“true”): The instance n of SysMLNode class is a

changed node;

The change type of a node can be addition, deletion or modification

The “shouldBeDeleted” property is employed to test whether a node

should be removed from a specific diagram In order to become a

de-leted node, two conditions should be satisfied:

•The node should be a changed node

•The diagram in which the node is deleted should contain a certain

deletion scenario

Therefore, the shouldBeDeleted(? n,“true”) relation can be defined

as:

∧

→

hasNode(? d,? n)

hasDeleteScenario(? d,“delete2”)

shouldBeDeleted(? n,“true”)

As a deleted node must be a changed node, a new rule is obtained

and can be defined as:

→

shouldBeDeleted(? n,“true”)

isChangedNode(? n,“true”)

Last, a change propagation rule library is established so as to

exe-cute semantic reasoning These rules are formalized through SWRL and

added into the inference engine, such as the Drools Some example rules

are given inTable 4 In addition, the rules are constructed from three perspectives

(1) Reinforcing the semantics of the SysML cross-cutting relationships (2) Improving the semantic relationships from changed model elements

to impacted model elements

(3) Identifying the change type and scenario of model elements that

reflect change propagation

4 Demonstration 4.1 Design of a water distiller system and problems when changing it

The design of a water distiller system is used in this section to de-monstrate the proposed approach The International Council on Systems Engineering (INCOSE) originally developed the example for the initial evaluation of SysML The MBSE method used for specifying the system includes six iterative steps[2]: (1) organize the model, (2) capture requirements, (3) analyze model behavior, (4) analyze model structure, (5) analyze performance of the current design, and (6) change the design based on change demands

After the first four steps, the initial system model is created by SysML, as displayed inFig 13 In step (5), a problem is recognized after analyzing the performance of the current design: The boiler will over-flow because there is no place for all the water used for condensing the steam to go Therefore, the design is not feasible and requires change

In step (6), the system requirement (Distiller Requirement), beha-vior (Distill Water), decomposition structure (Distiller Breakdown) and internal structure (Distiller Internal Structure) are changed to address the initial design according to the change demand, i.e., provide enough space to store water so that the system does not overflow

However, during the change process, designers have to determine manually which model elements should be changed and what impact change propagation has on other model elements in related diagrams Fig 14exhibits changed SysML diagrams, change types and the number

of added, deleted and modified elements in step (6) In a practical change case, although the initial demand is just to add a new require-ment in the requirerequire-ment diagram, its impact is huge, which makes the work long and tedious As a result, it is hard for a designer not to make mistakes like forgetting to delete a model element impacted by a change or adding model elements in an irrelevant diagram

4.2 Using the ontology and rules to improve the change process

In order to improve the efficiency of the change process, informa-tion about the system model is documented in the change propagainforma-tion ontology, and rules are executed to help modelers identify impacted model elements with change types

Protégé (http://protege.stanford.edu) and the Drools rule engine that supports the execution of SWRL rules in Protégé are used for

Table 4

Some SWRL rules defined in the change propagation information ontology.

trace(? r,? a) satisfy(? b,? r) allocate(? a,? b) Traceability is complemented by semantic relationships.

contain(? x,? y) isChangedNode(? x,“true”) isImpactedNode(? y,“true”) A changed requirement impacts its sub-requirements.

satisfy(? b,? r) isChangedNode(? r,“true”) isImpactedNode(? b,“true”) A model element is impacted by a changed and related model element.

satisfy(? b,? r) isChangedNode(? r,“true”) isImpactedNode(? b,“true”)

→ propagateTo(? r,? b)

Change is propagated from a changed model element to an impacted model element.

hasAction(? x,? a) hasBlock(? y,? b) allocate(? a,? b) isChangedNode(? x,“true”)

∧ isChangeDiagram(? x,“true”) → isImpactedDiagram(? b,“true”)

A diagram is changed due to changes of model elements in other diagrams.

∧

hasEdge(? d,? e) hasDeleteScenario(? d,delete1)

→ shouldBeDeleted(? e,“true”)

Change type of a model element is tested by the change scenario in its SysML diagram.

hasNode(? d,? n) withEdge(? n,? e) shouldBeModified(? n,“true”)

→ shouldBeModified(? e,“true”)

A model element should be changed when there is a changed and related model element.

modeling the ontology and processing the reasoning.Fig 15conveys a

graphical view of the reasoning framework, illustrating the

relation-ships between the change propagation information ontology and the

rules Information of the SysML-based system model is documented as

individuals, properties and axioms of the OWL ontology by the Protégé

ontology editor (Fig 16) Corresponding SWRL rules and appropriate

OWL knowledge are transferred to the Drools rule engine, which runs,

and then, passes the inferred knowledge back to Protégé

Distiller system requirements are changedfirst A new requirement

named S6.0 (Provide Space) should be added in the requirement

dia-gram It is derived from requirement S2.0 (Heat Exchanger) and S3.0

(Boiler) Based on Section3.2, the change type is an addition and the addition scenario is“add_2”, which is created as properties of the cor-responding model elements

Second, the impact of the requirement change is specified and identified through running the reasoning engine The result (Table 5) conveys that the impacted diagram is the Distill Water activity diagram, and the impacted elements are the Condense Steam, Heat Water and Boil Water actions, their pins and the objectflow between them The next step is to change the activity diagram In order to meet new requirement S6.0, an action called Divert Feed should be added The change process includes deleting objectflow between the Heat Water and Boil Water actions, inserting the new action, adding corresponding pins and new objectflows, and modifying their layout Therefore, three types of change are involved The change scenarios are “delete_1”,

“modify_1”, “modify_2” and “add_2” Rules are executed The result in Table 6shows that the impacted diagrams are the Distiller Breakdown Structure BDD and Distill Internal Structure IBD In the BDD, the dis-tiller block is impacted; in the IBD, the“shouldBeDeleted” property of

<<trace>>

<<allocate>>

<<satisfy>>

<<allocate>>

<<depend>>

Fig 13 Initial system model and relationships among diagrams [2]

Number of

changed

elements

Changed SysML Diagram Distiller

Requirement

(Req)

Distill Water (Act)

Distiller Internal Structure (IBD)

Distiller Breakdown (BDD)

5

10

2

6

11

3 2

2

0

9

1

9

0 Addition Deletion Modification

Fig 14 Changed model elements in each SysML diagram.

Change propagation

Protégé ontology editor

Drools rule engine OWL+SWRL->Drools Drools->OWL

Fig 15 Reasoning framework using the Protégé and Drools rule engine.

interface main2: H2O between the condenser and evaporator blocks is

“true” due to the change propagated from the deletion in the activity

diagram, and the impacted blocks “shouldBeMmodified The change

process enables designers to understand that adding a new requirement,

S6.0 Provide Space in the requirement diagram, requires adding a new

action named Divert Feed and deleting the correspondingflow in the

activity diagram, such as the H2O stream between the Heat Water

ac-tion and the Boil Water acac-tion

In the same way, the BDD and IBD can be changed with the help of the reasoning capability Due to the paper’s limited space, the detailed change is not discussed The identified impacted elements and change types are listed inTable 7 However, the shouldBeAdded properties that are in italics inTable 7are identified manually not automatically, be-cause there is no way to extract semantic information from uncreated model elements The reason is that, for the system to identify a neces-sary addition, any added scenario due to changed model elements would have to be specified in advance For instance, when a block re-presenting a new component is added in a specific IBD, the addition of input or output pins needs to be identified based on the semantics of the scenario; therefore, the addition of the new component cannot be identified automatically

4.3 Discussion

In the design of the water distiller system, SysML diagrams, model elements, changed information, their semantic relations and properties are explicitly represented and documented based on the ontology More significantly, according to the general process of changing the system

Fig 16 Partial ontology of the distiller system re-quirements.

Table 5

Partially identified impact from the requirement change.

Reasoned property Domain Range

isChangedDiagram Distiller_System_Requirements true

isImpactedDiaram Distill_ Water true

impactDiagram Distiller_System_Requirements Distill_ Water

propagateTo S6.0 (requirement) Condense_Steam

propagateTo S6.0 (requirement) Heat_Water

propagateTo S6.0 (requirement) Boil_Water

shouldBeModified S6.0 (requirement) true

shouldBeModified derive_S2.0 (deriveLink) true

Table 6

Some identified impacts from the change behavior.

isChangedDiagram Distill_Water true

isImpactedDiagram Distiller_Decomposition_Structure true

impactDiagram Distill_Water (activity diagram) Distiller_Breakdown_Structure

propagateTo Heat_Water (action) distiller (block)

shouldBeModified evaporator (block) true

isImpactedDiaram Distill_Internal_Structure true

impactDiagram Distill_Water (activity diagram) Distill_Internal_Structure

propagateTo of2 (object flow) main2: H2O

shouldBeDeleted main2: H2O (interface) true

propagateTo Heat_Water (action) condenser (block)

propagateTo Heat_Water (action) evaporator (block)

shouldBeModifed distiller (block) true

shouldBeModified condenser (block) true