(SCPSs) consist of networked social, physical, and software subsystems, including business processes, social networks, Internet-of-Things (IoT) devices, and software components. Examples include existing systems, such as ones for air traffic control, and emerging ones, such as smart homes/cities [1
], adaptive Systems of Systems (SoS) [2
], and intelligent production networks [3
]. SCPSs have emerged as diverse, complex systems that raise new challenges for systems engineering. Engineers developing such systems need to consider software, hardware, and stakeholder concerns as well as runtime decisions for SCPSs that need to adapt to their operational environment (i.e., adaptive
As reported in a recent literature review [4
], model-driven engineering methods, e.g., using the Systems Modeling Language
], which supports system specification, and goal-oriented requirements engineering techniques, which support social concepts and strategic decision making, have been used in the recent past to handle the complexity of such systems.
Moreover, the integration of goal models with all system development and evolution activities provides unprecedented opportunities for helping engineers understand and validate system functionality, behavior, and quality in a holistic way [6
]. Traceability should, hence, be specified between goals, system requirements, design elements, and implementation components [9
] as this facilitates and enhances system development and evolution. A comprehensive engineering methodology for building SCPSs should also support consistency and completeness checks, verification, validation, change management, and impact analysis [10
A common approach across the literature is to develop goal models and remodel
them inside SysML design tools, e.g., by capturing goal models using extensions of requirements or use-case diagrams, and then link them to design elements [12
]. In the frequent case where the goal models were created in a different modeling environment that supports goal-oriented analysis, this often causes duplication of work, additional effort and time, and the introduction of inconsistencies [4
]. Visualization, filtering, and analysis techniques are essential to help developers track the connected element, detect incomplete and inconsistent elements, and determine the impact of changes. All of these techniques are not well supported by modeling tools. Consequently, to support these activities, existing approaches tend to [4
Develop a new tool to facilitate and simplify tracking methods by slicing the connected models to create simple and easy-to-follow views. However, developers have to check the consistency and completeness manually using these views, which could provide misleading information if some links are missing or incorrect.
Export the models after linking them using requirements or use-case diagrams and importing them into external tools, such as Excel, which also does not provide good support for different types of analyses and visualizations.
Provide little guidance or suggestions about (i) how to exploit the created links to assess consistency and completeness across multiple views or models, (ii) the impact of the changes, and (iii) any type of analysis.
For the above reasons, we are interested in developing a comprehensive engineering methodology for SCPSs. As a starting point, we recently proposed a modeling framework called CGS4Adaptation [13
] that integrates the goal-oriented requirement language, SysML, and feature models, to support through models the development process from requirement analysis to implementation with minimal work duplication or information loss.
SysML reuses a subset of UML with extensions that target systems engineering, e.g., to model designs that combine hardware and software components. SysML includes UML use case, sequence, activity, and state-machine diagrams and is useful for modeling SCPSs. Due to its language features, it simplifies system design [16
] and reduces complexity [17
] by providing block definition and internal block diagrams from UML class diagrams. In addition, SysML includes parametric and requirement diagrams not included in standard UML to relate a system’s design to its requirements [18
]. However, the latest SysML standard [5
] does not include important first-class concepts for modeling and analyzing social concepts, such as goals, indicators measuring their degree of satisfaction, and contributions that indicate the impact of satisfying a goal on other related goals.
To supplement the concepts found in SysML for capturing social concepts in SCPSs, a complementary goal-oriented modeling language (such as KAOS [19
], or others [21
]) can be used. Among these many options, we adopt the Goal-oriented Requirement Language
], which enables modeling and analyzing the goals of both a socio-cyber-physical system-to-be and the social actors who participate in its activities. GRL is also part of the User Requirements Notation
(URN) standard [22
]. In addition to design alternatives, GRL supports self-adaptive systems through quantitative and qualitative trade-offs and what-if analysis, which can be conducted inside and outside goal modeling tools.
To support evidence-based decision-making with the best adaptation alternatives according to the current context, GRL uses key performance indicators (KPIs) to monitor the surrounding environment [22
] while propagating their values to measure overall system satisfaction that can be used to adapt accordingly [13
The CGS4Adaptation framework [13
] (Figure 1
) integrates three modeling languages for the development of SCPSs in a way that enables adapting to user concerns through monitoring quality and compliance:
SysML, for capturing concerns related to software and hardware.
GRL, for capturing stakeholder concerns and preferences as well as indicators for measuring them.
Feature models [24
], captured with an extension of GRL, for specifying variability and adaptation opportunities.
The CGS4Adaptation framework consists of two complementary parts supporting traceability and self-adaptation. The first integrates GRL and SysML models using a third-party traceability system (e.g., a requirement-management system) while the second transforms goal and feature models to mathematical functions for effective and efficient goal-based reasoning and adaptation in SysML models (at design time) and in implementations (at runtime) [13
]. SysML design environments can be used to support simulation, optimization, and code generation of SCPSs, using the functions generated from goal/feature models.
This paper focuses on the area of CGS4Adaptation delimited by the dashed line in Figure 1
and on the RMS-based management and exploitation of traceability between goal models, SysML models, and conventional natural language requirements. An RMS-based solution is meant to help engineers benefit from existing capabilities to manage traceability links, track changes and their impact through these links, and provide sophisticated analysis, visualization, and filtering techniques instead of using design tools that lack (or do not well support) such capabilities. These differences will be further discussed in the related work (Section 3
In previous work [25
], we explored exporting GRL and feature models from the jUCMNav [26
] tool and SysML models from Cameo Systems Modeler [27
] to runnable scripts that IBM Rational DOORS [28
] runs to import and store the elements of these models and their relationships. DOORS, a popular RMS, can then be used to manage traceability links between the models and to/from conventional requirements. Preliminary completeness and consistency rules are also introduced to support the traceability management process and improve alignment. Completeness is used to assess whether elements in one model are properly addressed (and linked) in another model, and violations at that level may lead to the addition or deletion of model elements or links. Consistency checks whether elements of appropriate types and natures are linked across models.
In this paper, we extend this previous work by contributing:
A comprehensive and practical model-based traceability and development method to integrate the social concerns modeled by a goal-oriented approach with SysML designs through a requirements management system (RMS).
One particular implementation of this method is provided for the GRL modeling language and for the DOORS RMS. Section 2
provides additional details on why GRL and DOORS were chosen.
Improved and systematic consideration for the goal-based rationale behind the requirements and design elements to facilitate system documentation, traceability, and its applications, including consistency and completeness checks, change management, and impact analysis. This includes:
The automation of consistency and completeness checks for goal and design models, implemented as executable scripts, accompanied by views and filters to improve the usability of the analysis. The proposed traceability information model (TIM) [11
] and the consistency and completeness rules are used to implement automatic checks that exploit the direct and indirect relationships between system goals, requirements, and blocks, in order to find alignment issues early and on a continuous basis.
The definition of new completeness and consistency rules to minimize development time and effort by detecting issues that are difficult to catch otherwise.
Documentation describing how existing features of RMSs (views and filters) can be used to visualize and solve consistency and completeness issues.
An evaluation of the efficiency and benefits of the proposed traceability approach using an illustrative IoT-based smart home case study provided by the SM@RT Team [31
] at the Informatics Research Institute of Toulouse. A smart home management system
(SHMS) is an adaptive SCPS supporting elderly stakeholders by performing activities, such as selecting a cost-effective energy provider or controlling heating/cooling and other smart home appliances. SHMSs are usually designed from scratch using available devices and often result in design errors [32
The proposed approach also takes advantage of existing tools and techniques to minimize coding errors and the effort needed for its implementation.
These contributions are of interest to practitioners and researchers who use model-oriented traceability management, goal-oriented modeling, or SysML modeling as it provides original tool-supported features and a method that combines three complementary modeling aspects and supports automated analysis. Many of these features can also be reused in contexts other than the one used here. The paper is of further interest to researchers as it raises awareness of specific challenges and solutions in developing SCPSs, while identifying other challenges that remain to be addressed.
The rest of the paper is structured as follows. Section 2
presents relevant background technologies, and Section 3
discusses closely-related work. Section 4
explains the proposed traceability management method in CGS4adaptation, including consistency and completeness checks. We evaluate this method using a smart home case study in Section 5
. Threats to the validity of this research are detailed in Section 6
. Finally, our conclusions and future work are presented in Section 7
2. Background Technologies
This section describes the modeling and RMS tools used in the CGS4Adaptation framework as well as existing technologies for importing models.
2.1. Goal Modeling Language and Tool: GRL and jUCMNav
GRL models are composed of actors that contain intentional elements (goals, softgoals, tasks, and resources) as well as indicators converting monitored information into satisfaction levels. Intentional elements can be connected via decomposition links (AND, OR, and XOR), contribution links (with weights going from to ), and dependencies.
is an Eclipse-based editor and analysis tool for the User Requirements Notation, including GRL [26
]. Different GRL analysis algorithms can be used to assess goal and actor satisfaction [22
]. jUCMNav has an open architecture that enables importing and exporting model information in various formats through custom plug-ins. jUCMNav also supports feature modeling (integrated with goal models) and enables exporting GRL and feature models as mathematical functions whose parameters are the satisfaction levels of the leaves of the models [13
GRL is an excellent candidate for integration with SysML because it supports actors and goals but also indicators for monitoring contexts in a way that enables quantitative analysis and self-adaptation decisions [34
]. This is also the only internationally standardized goal modeling language at this time.
2.2. SysML Modeling Tool: Cameo Systems Modeler
SysML is supported by many modeling, analysis, and code generation environments [35
]. Among them, we find Cameo Systems Modeler
], a model-based systems engineering (MBSE) tool from Dassault Systèmes (formerly No Magic Inc.) based on the MagicDraw Modeling Platform. It supports SysML, including package, requirement, block definition, internal block, activity, use case, and parametric diagrams. This tool was particularly selected for CGS4Adaptation because it can be used to simulate and analyze SysML models, and it can support exporting model information using report templates (described using the Velocity Template Language
]), a feature that indirectly enables some level of integration with an RMS.
2.3. RMS: IBM Rational DOORS
There exist many mature tools, commercial or otherwise, for managing requirements and for exploiting traceability links (see, for example, INCOSE’s SETDB Explore Tools list
, accessed on 11 January 2023). Very few, however, offer extensible integration interfaces, scriptable automation, and an opportunity to import models, or parts thereof, from other tools (beside preexisting bridges that might be provided). This is why we became interested in DOORS as an RMS for CGS4Automation in general, and for this paper in particular.
IBM Rational’s Dynamic Object Oriented Requirements System
] is a leading enterprise-level requirement-management tool, often used by requirements engineers involved in CPS development. DOORS manages extensive information to control system compliance with its requirements and facilitates communication and cooperation between cross-functional teams collaborating on a same project.
In addition to capturing typed requirements and typed links between them (with their attributes), DOORS traces and analyzes changes to requirements, providing several views of their impact on the product as a whole. This paper’s method exploits and takes advantage of DOORS to trace system artifacts (goals, requirements, and designs) and their changes across development phases, thus, helping to ensure that the system design is continuously in compliance with its system requirements, goals, and quality requirements. However, in order to manage traceability between modeling artifacts, the latter must be first stored in the DOORS database.
A DOORS database contains folders, projects, and modules. A project is a type of folder that may hold other folders and modules. An object is the core element of the database and represents the concept that we want to trace (e.g., a requirement, a GRL goal, or a SysML block).
Each object has a type and may contain additional predefined and user-defined attributes (e.g., status, author, and priority). In the database, a formal module
contains the objects in a specific order and forms a particular unit (e.g., a system requirements specification, a software requirements specification, or a test suite) whereas a link module
holds the traceability links between these objects. Link modules essentially define link types (e.g., “refine”, “satisfies”, or “tests”) according to a traceability information model [11
]. Link instances, visualized in formal modules with triangular annotations, are typically used for navigation between objects, impact analysis, coverage analysis, change propagation, and document generation.
The DOORS eXtension Language
(DXL) is a domain-specific language (DSL) used by DOORS to extend its features. DXL is a scripting language used to create, delete, modify, and navigate objects, links, and attributes in the database [37
]. DXL scripts can also be created to automate various update and validation activities.
DOORS does not support modeling out of the box. However, our approach uses DOORS as an RMS for storing and linking SysML and GRL models in a way that supports completeness and consistency analysis, in addition to out-of-the-box impact analysis.
2.4. Model Import DSL (MI-DSL)
The integration of modeling tools can be performed using technologies, such as the Open Services Lifecycle Collaboration
(OSLC) standard [38
], which manages a loose integration between modeling tools and a RMS with changes synchronization. However, not all tools support OSLC, particularly in the Eclipse world where many modeling tools exist.
The MI-DSL environment represents an alternative to OSLC. MI-DSL is a textual DSL used to specify the desired subset of a modeling language whose model instances need to be traced and managed in DOORS [39
]. MI-DSL facilitates model import and synchronization (through re-importing models) by generating a DXL library automatically from a modeling language description. This library can then be used to “execute” models exported to DXL, and import their elements, attributes, and links to DOORS. MI-DSL is supported by an Eclipse-based editor (defined with Xtext [40
]) that generates the DXL library automatically (via Xtend transformations [41
]). Figure 2
describes the metamodel of this DSL.
MI-DSL includes the following concepts:
Class: Describes the modeling language concepts selected for import in the DOORS database. Classes have typed attributes and are linked together through typed associations.
Attribute: Belongs to a class and specifies the name, type, and default value of an attribute.
Association: Belongs to a class and refers to another class. Associations are used to create link sets in DOORS.
DataType: Describes attribute types (Boolean, int, string, text, and diagram).
AssociationType: Describes association types used to create link modules in DOORS.
Module: Is a collection of classes that have similar or compatible attributes.
Folder: Contains modules.
Model: Contains folders. For each generated library, there is exactly one model instance.
MI-DSL is typically used as described in Figure 3
. First, starting from a language metamodel (a), the elements, attributes, and links to be tracked in the RMS (in essence, the desired TIM described as an instance of the metamodel in Figure 2
) are selected and coded using the MI-DSL editor (b). This is usually performed once per language per project. The MI-DSL editor then generates a DXL library automatically (c) through the use of Xtend-based transformations [39
]. The MI-DSL editor and code generator are available at https://github.com/Smart-Contract-Modelling-uOttawa/Traceability/tree/main/MI-DSL
(accessed on 11 January 2023).
The tool that supports the modeling language (d) also needs to generate DXL code (e.g., using a plug-in in Eclipse or report templates in VTL), and this is, again, performed once per tool per project. A DXL script can then be generated automatically from each model created by this tool (e). These scripts describe the model elements, attributes, and links of interest, as specified in the MI-DSL description, and invoke the library generated in (c). DOORS can then be used to run such scripts to import a model in its database, or re-import new versions of that model when it evolves (with appropriate warnings).
MI-DSL was used in the past to support importing models in various languages, including Finite State Machine (FSM), the User Requirements Notation (including links between URN’s goal and process views), and aspect-oriented URN [39
]. Prior to this paper, MI-DSL had never been used on SysML, on a commercial tool, or in a non-Eclipse-based environment.
In this paper, we evolved an existing plug-in for jUCMNav (a) to export the GRL elements required by our traceability information model (b). Similarly, we also created a new VTL-based export mechanism for Cameo Systems Modeler that generates DXL code describing the SysML elements, attributes, and links of interest. Two DXL libraries (c), one for each tool, enable importing evolving GRL and SysML models in DOORS. We also improved the MI-DSL infrastructure itself along the way to fix several bugs and make it more robust.
3. Related Work
The need to integrate goals with a system design has been addressed in the literature in multiple ways to support CPSs development and reuse—for instance, with profiles within SysML or through integration with external languages. A recent literature review by Anda and Amyot [4
] discussed the state of the art in combining SysML with goal modeling for designing adaptive systems.
To reach effective strategic business alignment, Cui and Paige [45
] integrated goals with SysML requirement diagrams via profiles, with extensions to the models and links for tracing and reasoning about requirements. However, they had simple goal models based on the Business Motivation Model standard [46
] and considered neither quantitative values of contribution relationships and alternatives between goals (which enable trade-off analysis) nor indicator parameters (which enable monitoring in adaptation contexts) in their extensions.
Ahmad et al. [47
] proposed a method to model and validate self-adaptive systems that uses profiles and stereotypes to extend the SysML requirements model with goals, softgoals, and their relationships. Again, this method does not capture indicators, the importance of intentional elements to actors, or contribution weights found in GRL models. In contrast, Badreddin et al. [48
] proposed a new textual language (fSysML) to integrate goals and SysML models using a textual syntax to support CPSs development process. However, their results are still preliminary without support for complex analysis or real traceability management.
To handle security goals and requirements, Maskani et al. [49
] modified the CompaSRE approach in a way that expanded the requirements profile with security goals and requirements by adding related goals, stakeholders, risks, and assets as attributes. Similarly, to validate complex systems for self-adaptation using requirements, Lee et al. [50
] extended SysML requirement diagrams with security requirements and some goal model elements to ensure they are functionally satisfied by a SysML state diagram that displays the information of system states.
To increase support for requirement reuse and reconfiguration in product lines, Wang [12
] proposed a multi-level requirement model by integrating textual goals (with AND/OR decomposition) with SysML use-case diagrams and by using a SysML tool to hierarchically classify the requirements in a requirement diagram. However, although they aimed to more systematically manage requirement traceability and facilitate reuse, they imported requirement data and relationships in different software tools (Excel, a spreadsheet, and Teamcenter—a product line management environment) to maintain requirements and their structure and relationships.
These relationships are represented as checkboxes related to each requirement (in Excel sheets) or as a tree structure (in Teamcenter) to remind engineers of the related requirements. Excel is unfortunately a weak RMS solution in general. Furthermore, their approach does not include all of the relationships found between their goals, which, consequently, leads to ignoring some dependencies and other relationships between requirements across related goals. To reinforce their approach, they recommended that system structure and other system development data should be included in their model, which is what our traceability management method does (among other things).
As relations between requirements and the top-level design aid in facilitating an accurate change impact analysis, Wang et al. [51
] proposed a traceability model focusing on the requirements of a command system-of-system. These requirements are characterized by their high number and complex relationships. The requirements are decomposed and hierarchically structured with SysML diagrams as a multi-layer requirement traceability model.
The model starts from strategy-task/goal-activity-capability and is mapped to use case, activity, and requirement diagrams to speed up design model updates according to changing requirements. Similar to some of the previous approaches, the impact of goals and tasks on each other across the structure was not considered in the created models. In addition, important traceability-related activities, such as automated consistency/completeness analysis and reporting are not supported.
In the same manner, given the difficulty in adjusting a system according to changing goals and requirements, Mimura et al. [52
] proposed a framework that combines elements of GQM+strategies [53
] and SysML requirement diagrams, again with a hierarchical structure. They extended the metamodel of GQM+strategies with new relationships to link goals and strategies in the GQM+strategies model with the root requirements of a SysML requirement diagram in order to enable consistency management. However, no explanation was provided on how the created links should be exploited to facilitate and simplify models to be reviewed and assessed by engineers.
Nejati et al. [54
] proposed a framework that includes a methodology for creating traceability links, a traceability information model, and a model-slicing algorithm. Once the main functions of the system are modeled with a use-case diagram, they are linked to safety requirements. These requirements are modeled in a requirement diagram and linked to the system design using SysML trace
links. To generate traceability reports and simplify the views used to check the consistency of the created links, the framework uses a tool (SafeSlice) that extracts parts of the created models (slices
) selected according to specific requirements. However, the extracted slices can provide incomplete/misleading information if some links are missing during the linking process.
To link the system goals and stakeholder goals of CPSs, a common approach across the literature [4
] is to remodel
these goals in SysML design tools without importing them from goal modeling tools. Such a strategy is time-consuming (work duplication), limited (not all goal model elements and relationships are usually included in or supported by design tools), error-prone (a manual process), and not scalable given the complexity of CPSs. In addition, traceability management activities, such as visualization, filtering, impact analysis, as well as consistency and completeness checks, are not well supported by design tools. There are also approaches that use profiles to manage traceability from SysML elements to functional and non-functional requirements and to stakeholders (see for example the work of Haidrar et al. [55
]), without supporting goals and their relationships explicitly, and often without support for automated consistency and completeness analysis and reporting.
Compared to the related work mentioned above, our traceability management method automatically integrates selected elements of interest from goal models (specified in a conceptually-rich and standardized language, namely GRL) and SysML system designs via an RMS with mature and diverse capabilities, without work duplication or information loss, even as models and other tracked artifacts (natural language requirements, tests, etc.) evolve. In addition, our method exploits imported intra-model relationships to save engineers time and effort when linking goals, requirements, and design components together. Useful and usable insights are provided using automatic consistency and completeness checks powered by the RMS ability to visualize, filter, and track a large number of model elements and their internal and external relationships.
One weakness of this method compared to approaches that only use a SysML modeling environment (or a SysML tool and an RMS) is to rely on the use of three tools (goal modeling environment, SysML environment, and third-party RMS) to support design and analysis activities. Our method risks hindering the overall usability (e.g., because of tool context switching) and productivity (e.g., due to the required model export/import activities). In many projects, this may, however, be a small price to pay compared to the cost of completeness and consistency issues discovered too late.
5. Smart Home Illustrative Case Study
We illustrate the feasibility and usefulness of the proposed method via an IoT-based smart home management system
case study that was first introduced in [25
]. This case study is based on the informal description provided by collaborators from the SM@RT Team [31
], in France. A smart home
is composed of in-home services that (i) support elderly and disabled people with the care needed to live independently in the home environment while (ii) providing them with a comfortable and secure life despite age and physical limitations.
We designed goal and SysML models of a self-adaptive SHMS that aims to effectively control most smart devices, such as smart thermostats, smart windows, and home electronics, with the ability to control electricity consumption and production as well as the comfort, privacy, and security of the inhabitants. Smart homes often rely on different IoT devices for monitoring external sources of information as well as for activity recognition inside the home [61
]. For simplicity, these are not discussed here, and GRL indicators are used as proxies for such monitored devices. Note that the models and corresponding DXL scripts are available online at https://github.com/Smart-Contract-Modelling-uOttawa/Traceability
(accessed 11 January 2023).
5.1. SysML Model
This section presents subsets of the goal and SysML models of the SHMS, including a GRL model created with jUCMNav and SysML block definition and requirement diagrams created with Cameo Systems Modeler.
5.2. Smart Home Requirements
The high-level requirements of the self-adaptive smart home management system are provided in Table 3
5.3. Smart Home Goal Model
We created a GRL model for SHMS according to the Smart Home case study description from [31
] and the requirements from Table 3
. The model is divided into several diagrams, which are shown in Figure 6
, Figure 7
and Figure 8
. In GRL, actors (dashed ellipses) contain intentional elements, which are mainly goals (rounded-corner rectangles), softgoals (clouds), and tasks (hexagons), together with indicators (hexagons with two lines at the top and bottom). AND/OR/XOR decomposition links are labeled accordingly, contributions are arrows annotated with a numerical positive/negative weight, and dependencies are shown with the filled D links. The small triangles indicate the existence of incoming/outgoing traceability links within the URN model in jUCMNav.
These three views of the GRL model are sufficient to illustrate the typical content of the goal model of a SCPS without going further into the specifics of the language or of the example, which are outside the scope of this paper. The construction of goal models in general (in GRL and other languages) is further discussed in the surveys of Horkoff et al. [21
] and Goncalves et al. [63
5.4. SysML Block Definition Diagram
The structure of the SHMS design is shown in a SysML block definition diagram (Figure 9
, Figure 10
and Figure 11
). These figures show the relationships between system blocks, including hierarchy relationships, associations, dependencies, and decompositions, in addition to the system requirements satisfied by these blocks.
illustrates the first level of decomposition of the Smart Home block, while the second level of decomposition is described in Figure 11
, where the Monitor block and its related blocks and constraint blocks are introduced. Furthermore, one level of generalization between the Smart device and its specific devices is shown in Figure 10
, where the blocks related to the Appliance controller block are described. Again, these three views are sufficient to illustrate how a typical SCPS can be modeled in SysML, and the interested reader is invited to refer to the work of Holt and Perry [64
] for general SysML modeling guidelines.
5.5. SysML Requirement Diagram
shows the SysML requirement diagram of the SHMS according to the requirements listed in Table 3
. The diagram shows a compound requirement (SmartHomeSystem) and the related sub-requirements (Economy, SecurityAndSafety, and Accommodation), in addition to their own derived and sub-requirements.
5.6. Importing the Models into the DOORS Database
We exported GRL models from jUCMNav and SysML models from Cameo Systems Modeler [27
] to DXL scripts (invoking our DXL libraries) that were then executed by DOORS. The result is that the elements of the goal and SysML models shown in the previous subsections are formally represented into the DOORS database using formal/link modules, objects, and attributes. Figure 13
shows the resulting formal and link modules of the goal and SysML models in DOORS.
5.7. Managing Inter-Model Traceability Links
We used DOORS to manually create new traceability links between the GRL, requirements, and block definition diagrams following the specified TIM (blue links in Figure 5
.b). Furthermore, we created specific DOORS linksets based on the nine link modules imported from GRL and SysML models to satisfy the directions and types of the links specified in the TIM:
A linkset in the Satisfy link module from the Intentional elements module to the Blocks module as shown in Figure 14
. In this linkset, we created the following Satisfy
links between intentional elements and Blocks modules.
From the Maximize security softgoal to the Smart security camera block;
From the Low-temperature and High-temperature indicators to the Smart thermostat block;
From the On ventilator and Off ventilator tasks to the Smart ventilator block;
From the Learning technique task to the Learning technique block;
From the Maximize comfort softgoal to the Smart device block;
From the Monitor the environment goal to the Monitor block (but we did not link all their children to the related block/intentional element);
From the Normalize goal to the Normalize temperature block (but we did not link its related goals and tasks to any block);
From the Internet task to the Internet block;
From the Wi-Fi task to the Wi-Fi block (but we did not link the owner block, Provide services, to any intentional element).
A linkset in the Satisfy link module from the Blocks module to the Actors module. We linked the System actor with the Smart home block and we assigned “True” to the ignore attribute of the Inhabitants actor in the Actors formal module (so that it would not create completeness or consistency issues).
A linkset in the Satisfy link module from the Blocks module to the Requirements module. These Satisfy links are created as follows: the Monitor block is linked with the Security and safety and Self-energy priority management requirements while the Assistance and support requirement is linked to the Provide services block. However, there are no links between their children (requirements or blocks) except for the links already imported from the SysML model between these children.
A linkset in the Traced by link module from the Requirements module to the Intentional elements module. In this linkset, the Manage appliances goal is linked to the Appliances management requirement while the Manage energy goal and the Maximize energy production softgoal are linked to the Self-energy priority management requirement. Furthermore, we connected the Minimize consumption softgoal with the Annual consumption management requirement.
Note that we have not connected all the elements together to explain the proposed rules and the benefits of the imported relationships. Creating traceability links could be completed semi-automatically, e.g., using natural language processing [59
]; however, this is outside the scope of this paper.
shows part of the consistency and completeness view of the Intentional elements module. The Provide services goal is not linked to any block or requirement, as seen in the ConsistencyAndCompleteness attribute, while its children (the WiFi and Internet tasks) are connected explicitly to the WiFi and Internet blocks and implicitly to the User preference requirement. This requirement is satisfied by the Provide services block, which is the parent of the WiFi and Internet blocks in the Blocks module (Rule #7 in Section 4.1.4
This relationship is an implicit one that is imported from the SysML model (see Figure 9
) and passed to all parts of the Provide services block during the consistency and completeness checks because these parts do not have any direct link to the requirements model.
Moreover, the Solar panel task does not have any link (there is no triangle next to the object name as shown in Figure 15
); however, it is considered to be linked to the Requirements and Blocks modules because its parent, the Manage energy goal, is linked to the Self-energy priority management requirement via a Trace
link (Section 5.7
). Using Rule #7, consistency and completeness checks propagate this relationship to all elements belonging to the Manage energy goal, including Solar panel, Smart grid, and Wind turbines.
Moreover, the implicit link check discovered a Satisfy
link from the Self-energy priority management requirement to the Energy controller Block (see Figure 9
), and so it passed this link to all the intentional elements related to this requirement. As a result, the Solar panel, Smart grid, and Wind turbines tasks are linked to the Requirements and Intentional elements modules using indirect links that engineers could not easily document otherwise.
Similarity, the Security and safety requirement is linked to the Monitor block, and thus this relationship is passed on to all of its constituent requirements that have no relationships with the Blocks module.
shows the test results where the Emergency and Physical intrusion detection requirements inherit the relationship with the Monitor block from their parent (the Security and safety requirement) while Fire detection does not since it is already connected to the Fire constraint block in the SysML model. In the same manner, implicit links are also discovered through the Monitor the environment goal that was linked to the Monitor block, so these links are passed on to the Emergency and Physical intrusion detection requirements. However, the Fire detection requirement obtained the same implicit link with the Monitor the environment goal but from the Fire block, which is part of the Monitor block. Furthermore, please note that the Appliances management requirement is a complete
requirement as it does not have any consistency or completeness issues.
From the consistency and completeness view of the Blocks module (Figure 17
), the Monitor block is consistent with the Intentional elements and Requirements modules, and its condition is transferred to its parts/children, including Motion sensors and Wind sensors, during the check.
Automating the verification of consistency and completeness rules and of implicit links enables better support for conventional impact analysis and change management analysis by helping to ensure that no link is missing and by showing relevant details about related elements in one usable view.
5.9. Analyze the Results and Apply Resolutions
After conducting the consistency and completeness checks, the results are saved in the related views. Some DOORS filters useful for the CGS4Adaptation framework, particularly regarding usability and efficiency, are presented below.
To display design elements that are not linked to goals and requirements, a filter can be applied to the Blocks module to select the objects with empty Intentional elements info and empty Requirements info attributes as illustrated in Figure 18
. The result lists 16 blocks and constraint blocks without a rationale (i.e., without a link to a requirement or to a goal). The engineer can then apply the resolution (Section 4.2.5
) most suitable for each issue and re-run the checks again.
To extract and review only the satisfied objects (linked to design) and traced objects (linked to requirements) in the Intentional elements module, a filter that extracts objects with a non-empty block info and a non-empty requirements info or a non-empty implicit link, can be applied. The result indicates that 37 elements (softgoals, goals, indicators, or tasks) are complete and consistent in the GRL and SysML models, listed in Figure 19
(right), while there are 39 incomplete or inconsistent elements as displayed in the statistics of Figure 19
The same filter is applied on the Requirements module to extract all the complete and consistent requirements. The results of this filter, not shown here, include 14 complete requirements (satisfied by blocks and traced to goals) and 6 inconsistent or incomplete requirements.
To list the requirements that have a rationale (linked to the goal model) but that are incomplete (not linked implicitly or explicitly to blocks), a filter that extracts the requirements linked to intentional elements but not to blocks is applied. The filter condition exploits the Implicit Link, Block Info, and Intentional Elements info attributes. The result of applying this filter indicates that the annual consumption management is the only incomplete requirement with a rationale. In this case, engineers can (1) bridge the gap and link this requirement to a related block, (2) ignore this requirement during the checks by assigning “True” to its Ignore attribute (which is a good option for non-operationalized requirements, such as “The color of the system shall be blue”), (3) delete the requirement, or (4) tolerate this issue and consider the project as not yet completed.
To list the incomplete requirements without a rationale, a complementary filter is applied. The result (not shown here) indicate four requirements with such issues, namely SmartHomeSystem, Economy, Energy saving, and Accommodation.
5.10. Case Study Observations
This case study demonstrated many benefits of our tool-supported traceability management method, including:
GRL goal models and SysML models (with requirement diagrams and BDDs) of a non-trivial SCPS can effectively be exported from modeling tools via MI-DSL and imported into the DOORS RMS.
The imported model elements are sufficiently granular to enable important inter-model traceability links to be created according to a TIM.
The seven consistency and completeness rules defined in Section 4.1.4
and automated through DXL scripts enable the detection of important and non-trivial traceability issues.
The use of parent–children relationships (inferred from the model’s internal links) and of implicit links by the rules reduce the manual effort required to create explicit intra-model links.
The “ignore” flag (one of the resolutions) enables ignoring model elements that are not meant to be covered by the rules and, hence, avoid many false positives when violations are detected.
The use of customized DOORS views and filters enables engineers to easily focus on explicit violations and their resolutions.
This section reports on the performance of many aspects of the method highlighted in Figure 3
and the algorithms of Section 4.2.3
. Although we do not provide a formal complexity analysis or a specific experiment targeting performance, we report several important observations. First, regarding the models used in this smart home case study:
The size of the SysML model is as follows. The Requirements module contains 20 requirements and 58 links related to requirements and other SysML elements. The 3 block definition diagrams contain 60 blocks and 60 embedded links as well as 79 inter-block links.
The GRL model contains 76 intentional elements, 155 relationships, and 2 actors. The elements and actors are linked to their diagrams via 78 links.
Regarding Figure 3
, where we use MI-DSL and import/export tools:
: Generating the DXL libraries (part c Figure 3
, e.g., for GRL and for SysML) from their respective MI-DSL descriptions (part b
) is fast and takes less than 2 s on a common Windows laptop. However, speed does not really matter here as this step is performed once per TIM.
Model Export: Regarding the generation of DXL scripts (part e) from modeling tools (part d), Cameo Systems Modeler takes less than 3 s to generate DXL scripts for the SysML model, whereas jUCMNav takes less than 2 s to generate scripts for the GRL model. Both export mechanisms simply navigate a model to generate files, and the complexity is linear with the number of elements and links in the model.
Model Import: To import models (part f), DOORS takes longer (but less than a minute) for importing the SysML and GRL models. Checking whether imported elements/links exist and creating, deleting, or updating them is an expensive process in a DOORS database. However, again, this is linear with the number of elements and links.
Finally, regarding the consistency and completeness checks between the goal and SysML models described by Algorithms 1 to 4:
A simple analysis of these algorithms suggests that these checks have a time complexity that is linearly proportional to the number of objects in the DOORS modules (the sequence of loops found in Algorithm 1) multiplied by how deep the objects are in their models. This depth results from the traversal of parent–child relationships defined in Algorithms 2 and 3, which use tail recursions (similar to a loop) and are invoked within the loops of Algorithm 1.
For the case study, DOORS takes several seconds to conduct the complete set of checks, including for explicit and implicit links. The checks go through all the objects; however, not all their links will be explored. Only links belonging to the current object for specific linkSets (i.e., satisfy, partOf, IsSharedBy, Dependency, refersTo, and childOf), and in specific directions are explored according to the introduced TIM.
Hence, in general, the time complexity is low (linear), and the performance is practical for the types of usage scenarios envisioned for this method.
7. Conclusions and Future Work
To support the development of SCPSs (and particularly adaptive ones), connecting social concerns and the design-time and run-time alternatives that satisfy these concerns to system requirements and design is a crucial need. This paper proposed a model-based method to manage the traceability between goal models expressed in GRL and the requirements and design artifacts modeled with SysML. The method supports many activities considered mandatory for SCPS development [66
This method enables GRL and SysML models to be efficiently created and analyzed in existing tools. By describing the elements of interest in such languages using MI-DSL, desired model elements and their attributes, relationships, and even diagrams can effectively be imported and re-imported (upon model changes) in the DOORS RMS. Using a powerful RMS, such as DOORS, enables sophisticated traceability and impact analyses, not often found in design tools, to be used out of the box.
In order to automate analysis that exploits inter-model links (created manually) and intra-model links (automatically imported), a traceability information model and related completeness and consistency rules were provided. The rules were implemented as executable programs (in DXL for DOORS) that navigate these links and report on inconsistency and incompleteness issues.
We took advantage of DOORS to manage traceability between the imported models while demonstrating how imported and manually-created links can be exploited to automatically check the consistency and completeness of the GRL and SysML models, possibly leading to additional changes in the models, to ensure that they are kept properly aligned. Relevant views and filters were provided to help engineers focus their attention on diverse types of reported issues and on their resolution. We evaluated the feasibility and usefulness of the traceability management method using an IoT-based smart home case study.
The overall results show that importing GRL and SysML models into DOORS to support traceability and alignment is feasible and beneficial. Note that the creation of an MI-DSL description for SysML, the creation of a VTL export script for Cameo Systems Modeler, the generation of DXL libraries and scripts, and the coding in DXL of automated consistency checks took the first authors less than two weeks of development time without any prior experience in MI-DSL, DXL, or VTL (we, hence, expect this to be faster for people with experience in such languages).
Moreover, the results suggest that rules can be checked through explicit links but also through implicit links, often resulting from transitive relationships, hence, detecting issues that cannot easily be spotted by engineers in large and complex models. The use of DOORS views and filters supports the usable management of the traceability information as well as the resolutions (linking, ignoring, or deleting elements or even tolerating an inconsistency) that must be made by engineers. Clean, consistent, and complete links further facilitate common change management and impact analysis processes to likely save engineers time and effort.
Note that these contributions do not all require the simultaneous existence of GRL together with SysML block definition and requirement diagrams. Within SysML, subsets different from the one used here could be involved. For example, requirement diagrams could be skipped if textual requirements exist elsewhere (as they would be redundant). This flexibility provides more opportunities for the above contributions to be used outside the SCPS context targeted by CGS4Adaptation.
The following research directions could be explored for further improvement and increased validity.
Further evaluation of the CGS4Adaptation framework and its new traceability management method could lead to additional improvements, particularly in terms of generality (e.g., regarding other traceability information models and application areas) and efficiency. This could include industrial case studies and usability studies. An application of CGS4Adaptation that would cover the entire development, implementation, and deployment cycles of a real-world self-adaptive system would be particularly relevant.
Exploring opportunities to bring GRL/feature modeling concepts and techniques directly into future versions of the SysML standard, in order to minimize the number of tools needed to support adaptive SCPS approaches, such as GS4Adaptation. The upcoming version 2.0 of SysML, whose work started in 2017 [67
], will likely include concepts for supporting concerns (akin to goals) and stakeholders [68
] but without specific relationships or indicators (which make the richness of a language, such as GRL).
MI-DSL provides some level of independence regarding the goal and SysML modeling tools used by our method. However, minimizing the dependency to a specific RMS (DOORS) remains an important topic that deserves much attention.
In a context where the traceability needs of a long-term project will evolve [69
], the TIM will likely need some modifications as well, which is a challenge [70
]. Providing mechanisms to generate consistency and completeness rules, views, and filters according to a custom-made or evolving TIM involving the goal and SysML languages would also bring important benefits in supporting the needs of projects.