- Email: [email protected]
IOCL: An interactive tool for specifying, validating and evaluating OCL constraints
Science of Computer Programming 149 (2017) 3–8
Contents lists available at ScienceDirect
Science of Computer Programming www.elsevier.com/locate/scico
Original software publication
IOCL: An interactive tool for specifying, validating and evaluating OCL constraints Muhammad Hammad a , Tao Yue a,b,∗ , Shuai Wang a , Shaukat Ali a , Jan F. Nygård c a b c
Simula Research Laboratory, Norway University of Oslo, Norway Cancer Registry of Norway, Norway
a r t i c l e
i n f o
Article history: Received 20 January 2017 Received in revised form 5 July 2017 Accepted 19 July 2017 Available online 16 August 2017 Keywords: OCL constraints Interactive tool UML models
*
a b s t r a c t The Object Constraint Language (OCL) is commonly used for specifying additional constraints on models, in addition, to the ones enforced by the semantics of the models. However, a lot of practitioners and even researchers are reluctant in using OCL to some extent due to the lack of sufficient familiarity with OCL. To facilitate practitioners and researchers in specifying OCL constraints, we designed and developed a web-based tool called interactive OCL (iOCL) for interactively specifying constraints on a given model. The core idea behind iOCL is to present and display only relevant details (e.g., operations) of OCL to users at a given step of constraint specification process, in addition to helping modelers with its syntax. We evaluated iOCL using a real-world case study from Cancer Registry of Norway and the results showed that iOCL can significantly reduce the time required to specify OCL constraints and decrease the possibility of making syntactic errors during the specification process. Thus, we conclude that iOCL can facilitate the process of OCL constraint specification. Interested users can try iOCL at: http://iocl.zen-tools.com/. © 2017 Elsevier B.V. All rights reserved.
Corresponding author. E-mail addresses: [email protected] (M. Hammad), [email protected] (T. Yue), [email protected] (S. Wang), [email protected] (S. Ali), [email protected] (J.F. Nygård). http://dx.doi.org/10.1016/j.scico.2017.07.006 0167-6423/© 2017 Elsevier B.V. All rights reserved.
4
M. Hammad et al. / Science of Computer Programming 149 (2017) 3–8
Software metadata (executable) Software metadata description Current software version Permanent link to executables of this version Legal Software License Computing platform/Operating System Installation requirements & dependencies If available Link to user manual – if formally published include a reference to the publication in the reference list Support email for questions
V1.1 https://github.com/ScienceofComputerProgramming/SCICO-D-17-00035 GNU General Public License (GPL) Java Virtual Machine Java 8, Tomcat 8 http://dnat.simula.no:50753/IOCL/docs.iocl [email protected], [email protected], [email protected], [email protected]
Code metadata Code metadata description Current Code version Permanent link to code/repository used of this code version Legal Code License Code Versioning system used Software Code Language used Compilation requirements, Operating environments & dependencies If available Link to developer documentation/manual Support email for questions
V1.1 https://github.com/ScienceofComputerProgramming/SCICO-D-17-00035 GNU General Public License (GPL) git Java Mac OS or Windows, Intellij idea IDE, Maven, Tomcat 8 http://dnat.simula.no:50753/IOCL/docs.iocl [email protected], [email protected], [email protected], [email protected]
1. Introduction Model-Based Engineering (MBE) aims at employing models (specified in for example Unified Modeling Language (UML) [8]) to facilitate the process of software development (e.g., model-based testing (MBT) [2][4]), which has been researched to a large extent in the recent decades [1–6]. To successfully apply a MBE solution in practice, the key challenge is to construct required models in a cost-effective manner. For example, applying a MBT solution requires test engineers to construct test ready models using a particular modeling language (e.g., UML), from which executable test cases can be generated [2]. In the past, we have developed a number of MBE solutions [1–6], most of which are based on UML and its profiles, and some of which require employing Object Constraint Language (OCL) to specify various constraints such as state invariants on states of a state machine (e.g., [1][2]). Based on our experience of applying OCL, we observe that practitioners and researchers are sometimes hesitant to apply OCL due to its declarative nature. Therefore, it is essential to seek an efficient and user-friendly means to assist practitioners and researchers to specifying OCL constraints. To specify OCL constraints in an efficient way, we designed and developed a web-based application called interactive OCL (iOCL) built on the top of several existing technologies: Eclipse Modeling Framework (EMF) [9], Eclipse OCL [10], Eclipse UML2 [11], and EsOCL [2]. Notice that we designed iOCL as a web application with the aim at easing users’ access to the tool without a need to download, install and configure before using. The core idea of iOCL is to guide modelers through constraint specification process step by step in an interactive manner. Generally speaking, iOCL consists of three types of user operations, i.e., selection operation, basic value input operation and text input operation. More specifically, the selection operation is to perform a choice from a list of available options provided by iOCL that are valid at a given step when specifying an OCL constraint. Notice that iOCL dynamically updates selection options based on the type of an UML model element, an association end multiplicity, or even the type of a collection resulting from one or more navigations from the contextual classifier. For the basic value input operation, users are required to input basic values for basic types (e.g., Integer, Boolean) at a given step of a specification process. In terms of the text input operation, a free text box is provided to users for input. Through these three user operations, a user dynamically interacts with iOCL during the process of OCL constraint specification. Notice that the goal of iOCL is to minimize the use of the basic value input operation and text input operation and maximize the use of the selection operation and thereby reducing the potential chances for users to make syntactic errors. Furthermore, more use of the selection operation can decrease the extent of OCL knowledge required since users will be guided by the available options provided by iOCL when specifying OCL constraints. We have conducted a pilot study in the form of controlled experiments, which is reported in [16], with the aim at evaluating iOCL using a real-world case study from Cancer Registry of Norway (CRN).1 Results of the pilot study show that 1) iOCL can manage to significantly reduce the time effort required for OCL constraint specification; 2) iOCL can decrease the possibility to make syntactic errors during the specification process and 3) the medical experts from CRN opinionated that iOCL is easy to use for specifying OCL constraints. This paper is an extended version of a tool demonstration paper [14] and the key differences are summarized as follows: 1) the motivation of iOCL is detailed and a brief background knowledge related with UML and OCL is presented for a wider range of readers; 2) the architecture, key features (functionalities) and implementation of iOCL is further elaborated;
1
Cancer Registry of Norway: https://www.kreftregisteret.no.
M. Hammad et al. / Science of Computer Programming 149 (2017) 3–8
5
3) results of a pilot study on evaluating iOCL are summarized; and 4) a comparison between iOCL and existing OCL-relevant tools is discussed. 2. Motivation and background Problem (motivation). A research collaboration was established since 2015 between Simula Research Laboratory and CRN with the aim at employing MBE to tackle the complexity of the evolving automated cancer registry system [1]. In our previous work [1], we proposed a model-based framework named MBF4CR to systematically capture domain knowledge (e.g., cancer messages) of CRN using UML and formally specify cancer coding rules (more than 1000) as OCL constraints. More details on MBF4CR can be found in [1]. While applying MBF4CR in CRN, we observed that medical experts (e.g., chief medical officers and medical coders) usually do not have sufficient knowledge to specify OCL constraints from scratch. Furthermore, the training process of using OCL is quite time-consuming and costly. Thus, it is practically challenging for medical experts (who have less familiarity of OCL) to understand and acquire all the notations and operations of OCL. Notice that such challenge we observed has also been raised and discussed in the MBE community [15], which become one of the key bottlenecks for applying MBE in practice. Therefore, it is of paramount importance to seek an efficient and user-friendly means to help practitioners to specify OCL constraints, which motivated us to design and develop iOCL. Background. Unified Modeling Language (UML) is a generic modeling language for capturing and visualizing certain information of a system at a higher level of abstraction [8]. UML has been widely applied in the field of software engineering [1][2][2][4] and has been standardized by Object Management Group (OMG), which is supported by a large number of tools [8], such as IBM Rational Software Architect (RSA) [17]. Due to the standardization and sufficient tool support of UML, it has been applied in diverse application domains, such as banking, healthcare and communications [1][2]. Object Constraint Language (OCL) is a declarative language to formally specify constraints on UML models, which is also an OMG standard [7]. Combined with OCL, UML can facilitate specification of systems/software in a more precise way. OCL constraints have been widely applied together with UML models to enable model-based testing and consistency checking of UML models [2][4]. Generally speaking, an OCL constraint can be specified for a variety of purposes such as defining constraints on a domain specific language, constraints on a UML profile, and constraints on UML models for a precise definition and to support automation. Comparison with the state-of-the-art software. There are several existing tools for specifying, evaluating and validating OCL constraints such as IBM RSA [17], Papyrus [18], and UML-based Specification Environment (USE) [19]. These tools provide integrated modeling environments to specify constraints in UML models using OCL. Moreover, Eclipse OCL [10] was designed to specify, validate and evaluate OCL constraints and EsOCL [3] was developed to take OCL constraints as input and automatically generate model instances that comply with the OCL constraints using search algorithms. As compared with the existing OCL tools, our iOCL tool poses at least two key differences: 1) iOCL focuses on easing the process of OCL constraint specification by interactively providing guidance, which has a different goal as compared with the existing OCL tools, and 2) iOCL integrates several existing OCL tools and supports their functionalities, i.e., Eclipse OCL and EsOCL. 3. Software framework 3.1. Software architecture The overall architecture of iOCL is presented in Fig. 1, which can be divided into two main parts, i.e., Front End and Back End. The Front End focuses on the interactions with users via a friendly interface. More specifically, the Query Analyzer is designed as an action listener used to: 1) monitor the actions sent from the Back End and 2) communicate with the Front End Controller. The Front End Controller takes charge of the actions and requests from users and dynamically displays the information produced by the Back End (e.g., selection operation or basic value input operation). Furthermore, iOCL defines a set of view templates, which are filled with properties and operations. Filled templates are returned to the users during a particular step during the process of OCL constraint specification. As for the Back End, the core is to handle various requests from the Front End (via Query Analyzer) and return the corresponding output to the Front End dynamically. By doing so, users can be provided with dynamic guidelines for specifying OCL constraints interactively. More specifically, as shown in Fig. 1, the Back End has five key parts, which include: 1) UML Model Reader: imports and parses an UML model, on which OCL constraints can be specified; 2) Constraint Specifier: specifies constraints for particular problems; 3) Constraint Validator: validates specified constraints in terms of syntax; 4) Constraint Evaluator: evaluates the correctness of specified constraints on particular UML model instances. By correctness, we mean there exist one or more valid model instances that can satisfy a specified OCL constraint, i.e., a given OCL constraint may not be correct if we cannot find any valid model instance that can satisfy it. Notice that iOCL analyzes each constraint independently for evaluating the correctness; and 5) Exporter: exports specified OCL constraints into required formats (e.g., .ocl files). Furthermore, as shown in Fig. 1, the Front End is implemented using the external package JavaServer Faces (JSF) [12], which is a well-known Java framework for developing user-friendly interfaces and web applications. The Back End is developed on the top of several external tools Eclipse UML2 [11] (for modeling software systems using UML), Eclipse OCL [10] (for validating and evaluating specified OCL constraints) and EsOCL [2] (for automatically generating model instances
6
M. Hammad et al. / Science of Computer Programming 149 (2017) 3–8
Fig. 1. An overview of the iOCL architecture.
that comply with the specified OCL constraints). Recall that iOCL is a generic web-based application, which can be tried at: http://iocl.zen-tools.com/. 3.2. Software functionalities Recall that iOCL aims to automate the OCL constraint specification process in a maximum manner. The key automation of iOCL is to dynamically shortlist available options at any given step, such that a user can perform the selection user operation in a more efficient way. Therefore, the first key feature (functionality) of iOCL is to systematically check the UML models, the already specified partial OCL constraint, and the current step of the specification process with the aim at providing users only relevant information (e.g., available options to choose) for the next step of specification process. The second key feature of iOCL is to automatically categorize types of constraints, OCL operations, and properties and only display relevant ones at a given step. This feature helps to reduce specification effort and potential syntactic errors that a user often makes when specifying an OCL constraint. Moreover, iOCL also allows a user to roll back to previous steps of a specification process in case there is anything missing. iOCL also automatically takes cares of bracket pairing and automatically fills out left and right brackets thus assisting a modeler with syntax. In addition, as described in Section 3.1, iOCL can evaluate the specified OCL constraints when there is a given UML model instance. When required, iOCL can also automatically generate model instances that satisfy a given set of specified OCL constraints.
M. Hammad et al. / Science of Computer Programming 149 (2017) 3–8
7
4. Empirical results To empirically evaluate iOCL, we have conducted a pilot study by employing a real-world case study from CRN [16], which includes an UML model for capturing the domain knowledge of CRN and 10 medical cancer coding rules. More details related with the domain knowledge of CRN and cancer coding rules can be found in [1]. More specifically, we involved four medical experts from CRN (one manager, two medical coders and one medical programmer) and asked them to specify the given ten cancer coding rules using iOCL. Notice that the selected ten cancer coding rules have not been specified as OCL constraints before. We recorded the time taken by each participant for specifying the OCL constraints and manually checked the syntax validity of the specified constraints afterwards. Notice that it took average 600 s for writing one OCL constraint manually from scratch based on our previous experience working with the medical experts for specifying cancer coding rules using OCL. In addition, more than 50% of the specified constraints were required to be further revised by involving experts for UML and OCL (e.g., the first four authors of the paper). The results of the experiment showed that it took average 259.9 s for each medical expert to specify one OCL constraint using iOCL, which managed to reduce 56.7% time effort as compared with specifying OCL constraints manually from scratch (600 s). We also performed the Wilcoxon Signed Rank test [1] to determine the significance of the results of specifying OCL constraints between using iOCL and without iOCL for specifying OCL constraints. The statistical test results showed that employing iOCL to specify constraints can significantly reduce time of constraint specifications as compared to the way without iOCL. Thus, we can conclude that applying iOCL can significantly reduce the time required for OCL constraint specification in practice due to iOCL’s good capability of providing dynamic guides. Moreover, we observed that all the OCL constraints specified by the four medical experts are 100% valid in terms of the syntax, which do not require additional effort for revising the specified constraints by involving UML/OCL experts. This is due to the fact that iOCL can dynamically assist users by providing valid syntax operations and provides warning/error notifications when the current specified OCL constraint is not valid. Thus, we can conclude that employing iOCL can indeed decrease the possibility of making errors during the specification process. We have also designed pre and post questionnaires with the aim at soliciting the views from the participants (the four medical experts) in terms of the usability of iOCL. The results showed that the medical experts from CRN found iOCL easy to use, which may have great potentials to be applied for specifying the medical cancer coding rules in the current practice of CRN. Notice that one of the key threats to validity is due to the small sample size used to derive conclusions. However, we have involved four real medical experts (as final users) for specifying ten OCL constraints followed by applying appropriate statistical tests for analyzing the results. We agree that more participants should be involved to further increase the sample size but it is worth mentioning we have involved all the medical experts who we are collaborating with at CRN. More details related with the experiment and threats to validity can be found in [16]. 5. Illustrative examples In this section, we illustrate how iOCL can be applied for interactively specifying OCL constraints using the publicly available case study named Royal and Loyal that was designed for the purpose of teaching OCL [13]. Notice that one can download this case study as .ecore file from the iOCL example website (including in total 12 UML classes and 10 OCL constraints). To start with iOCL, one can select an UML model with the format of .uml or .ecore and all of the model elements of a loaded model are automatically displayed in the list, from which one can select one as the contextual element to specify an OCL constraint. One can also select the context from the dropdown Context Selection list. When one selects the context, iOCL automatically displays a list of options such as Invariant, Pre Condition, Post Condition. A user can also roll back to her/his previous selection step via the Back button. When a user selects the context, a list of options is displayed in the Attribute Scope pane. When the user finishes the specification, she/he can click the Validate button to validate the syntactic correctness of the specified constraint and results will be returned to the user immediately. One can also switch from one panel to another, if needed. During the specification process, one can switch to Operation Type panel, which triggers the display of a list of operation types such as Comparison Operation. Last, one can also evaluate the specified constraint based on predefined instances by clicking the Evaluate button. We have created a video to illustrate how to use iOCL, which can be found in: https://www.youtube.com/watch?v=Wgi9YYMp7Q4. iOCL can also help in assessing the correctness of the specified constraint relying on EsOCL [2]. The constraint is correctly specified. If it is solvable, when EsOCL can solve the constraint by providing a valid UML model instance satisfying the constraint. Otherwise, there are two options: 1) EsOCL needs more iterations to solve the specified constraint; or 2) The specified constraint is not solvable. Notice that iOCL can provide users with syntax error information of specified OCL constraints and evaluate their correctness. However, iOCL cannot provide suggested solutions for fixing invalid OCL constraints and this will be investigated as our future work. 6. Conclusion Specifying OCL constraints requires in-depth OCL knowledge from the practitioners and researchers, which is one of the key bottlenecks for applying MBE in practice. To tackle this challenge, we designed an interactive OCL constraint specification tool called iOCL with the aim of assisting users in specifying OCL constraints in an interactive manner. The underlying idea
8
M. Hammad et al. / Science of Computer Programming 149 (2017) 3–8
is to present only the relevant details to a user at a given step of constraint specification process in addition to pre-filling the syntax with the aim of reducing the OCL knowledge required to specify constraints and ultimately reducing the training cost of using OCL. iOCL can also check the syntax of the specified constraints and evaluate their correctness with predefined instances and/or with the automated generated ones. Acknowledgements This work was supported by the MBE-CR (No. 239063) project funded by the RFF Hovedstaden. Tao Yue and Shaukat Ali are also supported by the Zen-Configurator 240024/F20 project, the EU Horizon 2020 project U-Test 645463 (Testing Cyber-Physical Systems under Uncertainty), the MBT4CPS 240013/O70 project and the RCN funded Certus SFI. Shuai Wang is also supported by the RCN funded Certus SFI and COST Action CA15140 (ImAppNIO). References [1] S. Wang, H. Lu, T. Yue, S. Ali, J. Nygård, MBF4CR: a model-based framework for supporting an automated cancer registry system, in: The European Conference on Modelling Foundations and Applications, Springer, 2016, pp. 191–204. [2] H. Lu, T. Yue, S. Ali, L. Zhang, Model-based incremental conformance checking to enable interactive product configuration, Information and Software Technology 72 (2016) 68–89. [3] S. Ali, M.Z. Iqbal, A. Arcuri, L.C. Briand, Generating test data from OCL constraints with search techniques, IEEE Transactions on Software Engineering 39 (2013) 1376–1402. [4] S. Wang, S. Ali, A. Gotlieb, M. Liaaen, A systematic test case selection methodology for product lines: results and insights from an industrial case study, Empirical Software Engineering 21 (4) (2016) 1586–1622. [5] M.Z. Iqbal, S. Ali, T. Yue, L. Briand, Applying UML/MARTE on industrial projects: challenges, experiences, and guidelines, Software & Systems Modeling 14 (2015) 1367–1385. [6] H. Lu, T. Yue, S. Ali, L. Zhang, Nonconformity resolving recommendations for product line configuration, in: International Conference on Software Testing, Verification and Validation, ICST, 2016, pp. 57–68. [7] Object Constraint Language (OCL), http://www.omg.org/spec/OCL/. [8] Unified Modeling Language (UML), http://www.omg.org/spec/UML/2.5/. [9] Eclipse Modeling Framework (EMF), https://eclipse.org/modeling/emf/. [10] Eclipse OCL, http://wiki.eclipse.org/OCL. [11] Eclipse UML2, http://wiki.eclipse.org/MDT-UML2. [12] JavaServer Faces (JSF), http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html. [13] Jcabot/ocl-repository, https://github.com/jcabot/ocl-repository/. [14] M. Hammad, T. Yue, S. Ali, S. Wang, iOCL: an interactive tool for specifying, validating and evaluating OCL constraints, in: ACM/IEEE 19th International Conference on Model Driven Engineering Languages and Systems (MODELS) Tool Demonstration Track, 2016, pp. 24–31. [15] M. Petre, UML in practice, in: 2013 International Conference on Software Engineering, 2013, pp. 722–731. [16] S. Ali, M. Hammad, H. Lu, S. Wang, T. Yue, A pilot experiment to assess interactive OCL specification in a real setting, Technical report (2017-01), available at: https://www.simula.no/publications/pilot-experiment-assess-interactive-ocl-specification-real-setting. [17] Rational Software Architect (RSA), https://www.ibm.com/developerworks/downloads/r/architect/. [18] Papyrus, http://www.eclipse.org/modeling/mdt/papyrus/33. [19] UML-Based Specification Environment, http://useocl.sourceforge.net/w/index.php/The_UML-based_Specification_Environment.
Contents lists available at ScienceDirect
Science of Computer Programming www.elsevier.com/locate/scico
Original software publication
IOCL: An interactive tool for specifying, validating and evaluating OCL constraints Muhammad Hammad a , Tao Yue a,b,∗ , Shuai Wang a , Shaukat Ali a , Jan F. Nygård c a b c
Simula Research Laboratory, Norway University of Oslo, Norway Cancer Registry of Norway, Norway
a r t i c l e
i n f o
Article history: Received 20 January 2017 Received in revised form 5 July 2017 Accepted 19 July 2017 Available online 16 August 2017 Keywords: OCL constraints Interactive tool UML models
*
a b s t r a c t The Object Constraint Language (OCL) is commonly used for specifying additional constraints on models, in addition, to the ones enforced by the semantics of the models. However, a lot of practitioners and even researchers are reluctant in using OCL to some extent due to the lack of sufficient familiarity with OCL. To facilitate practitioners and researchers in specifying OCL constraints, we designed and developed a web-based tool called interactive OCL (iOCL) for interactively specifying constraints on a given model. The core idea behind iOCL is to present and display only relevant details (e.g., operations) of OCL to users at a given step of constraint specification process, in addition to helping modelers with its syntax. We evaluated iOCL using a real-world case study from Cancer Registry of Norway and the results showed that iOCL can significantly reduce the time required to specify OCL constraints and decrease the possibility of making syntactic errors during the specification process. Thus, we conclude that iOCL can facilitate the process of OCL constraint specification. Interested users can try iOCL at: http://iocl.zen-tools.com/. © 2017 Elsevier B.V. All rights reserved.
Corresponding author. E-mail addresses: [email protected] (M. Hammad), [email protected] (T. Yue), [email protected] (S. Wang), [email protected] (S. Ali), [email protected] (J.F. Nygård). http://dx.doi.org/10.1016/j.scico.2017.07.006 0167-6423/© 2017 Elsevier B.V. All rights reserved.
4
M. Hammad et al. / Science of Computer Programming 149 (2017) 3–8
Software metadata (executable) Software metadata description Current software version Permanent link to executables of this version Legal Software License Computing platform/Operating System Installation requirements & dependencies If available Link to user manual – if formally published include a reference to the publication in the reference list Support email for questions
V1.1 https://github.com/ScienceofComputerProgramming/SCICO-D-17-00035 GNU General Public License (GPL) Java Virtual Machine Java 8, Tomcat 8 http://dnat.simula.no:50753/IOCL/docs.iocl [email protected], [email protected], [email protected], [email protected]
Code metadata Code metadata description Current Code version Permanent link to code/repository used of this code version Legal Code License Code Versioning system used Software Code Language used Compilation requirements, Operating environments & dependencies If available Link to developer documentation/manual Support email for questions
V1.1 https://github.com/ScienceofComputerProgramming/SCICO-D-17-00035 GNU General Public License (GPL) git Java Mac OS or Windows, Intellij idea IDE, Maven, Tomcat 8 http://dnat.simula.no:50753/IOCL/docs.iocl [email protected], [email protected], [email protected], [email protected]
1. Introduction Model-Based Engineering (MBE) aims at employing models (specified in for example Unified Modeling Language (UML) [8]) to facilitate the process of software development (e.g., model-based testing (MBT) [2][4]), which has been researched to a large extent in the recent decades [1–6]. To successfully apply a MBE solution in practice, the key challenge is to construct required models in a cost-effective manner. For example, applying a MBT solution requires test engineers to construct test ready models using a particular modeling language (e.g., UML), from which executable test cases can be generated [2]. In the past, we have developed a number of MBE solutions [1–6], most of which are based on UML and its profiles, and some of which require employing Object Constraint Language (OCL) to specify various constraints such as state invariants on states of a state machine (e.g., [1][2]). Based on our experience of applying OCL, we observe that practitioners and researchers are sometimes hesitant to apply OCL due to its declarative nature. Therefore, it is essential to seek an efficient and user-friendly means to assist practitioners and researchers to specifying OCL constraints. To specify OCL constraints in an efficient way, we designed and developed a web-based application called interactive OCL (iOCL) built on the top of several existing technologies: Eclipse Modeling Framework (EMF) [9], Eclipse OCL [10], Eclipse UML2 [11], and EsOCL [2]. Notice that we designed iOCL as a web application with the aim at easing users’ access to the tool without a need to download, install and configure before using. The core idea of iOCL is to guide modelers through constraint specification process step by step in an interactive manner. Generally speaking, iOCL consists of three types of user operations, i.e., selection operation, basic value input operation and text input operation. More specifically, the selection operation is to perform a choice from a list of available options provided by iOCL that are valid at a given step when specifying an OCL constraint. Notice that iOCL dynamically updates selection options based on the type of an UML model element, an association end multiplicity, or even the type of a collection resulting from one or more navigations from the contextual classifier. For the basic value input operation, users are required to input basic values for basic types (e.g., Integer, Boolean) at a given step of a specification process. In terms of the text input operation, a free text box is provided to users for input. Through these three user operations, a user dynamically interacts with iOCL during the process of OCL constraint specification. Notice that the goal of iOCL is to minimize the use of the basic value input operation and text input operation and maximize the use of the selection operation and thereby reducing the potential chances for users to make syntactic errors. Furthermore, more use of the selection operation can decrease the extent of OCL knowledge required since users will be guided by the available options provided by iOCL when specifying OCL constraints. We have conducted a pilot study in the form of controlled experiments, which is reported in [16], with the aim at evaluating iOCL using a real-world case study from Cancer Registry of Norway (CRN).1 Results of the pilot study show that 1) iOCL can manage to significantly reduce the time effort required for OCL constraint specification; 2) iOCL can decrease the possibility to make syntactic errors during the specification process and 3) the medical experts from CRN opinionated that iOCL is easy to use for specifying OCL constraints. This paper is an extended version of a tool demonstration paper [14] and the key differences are summarized as follows: 1) the motivation of iOCL is detailed and a brief background knowledge related with UML and OCL is presented for a wider range of readers; 2) the architecture, key features (functionalities) and implementation of iOCL is further elaborated;
1
Cancer Registry of Norway: https://www.kreftregisteret.no.
M. Hammad et al. / Science of Computer Programming 149 (2017) 3–8
5
3) results of a pilot study on evaluating iOCL are summarized; and 4) a comparison between iOCL and existing OCL-relevant tools is discussed. 2. Motivation and background Problem (motivation). A research collaboration was established since 2015 between Simula Research Laboratory and CRN with the aim at employing MBE to tackle the complexity of the evolving automated cancer registry system [1]. In our previous work [1], we proposed a model-based framework named MBF4CR to systematically capture domain knowledge (e.g., cancer messages) of CRN using UML and formally specify cancer coding rules (more than 1000) as OCL constraints. More details on MBF4CR can be found in [1]. While applying MBF4CR in CRN, we observed that medical experts (e.g., chief medical officers and medical coders) usually do not have sufficient knowledge to specify OCL constraints from scratch. Furthermore, the training process of using OCL is quite time-consuming and costly. Thus, it is practically challenging for medical experts (who have less familiarity of OCL) to understand and acquire all the notations and operations of OCL. Notice that such challenge we observed has also been raised and discussed in the MBE community [15], which become one of the key bottlenecks for applying MBE in practice. Therefore, it is of paramount importance to seek an efficient and user-friendly means to help practitioners to specify OCL constraints, which motivated us to design and develop iOCL. Background. Unified Modeling Language (UML) is a generic modeling language for capturing and visualizing certain information of a system at a higher level of abstraction [8]. UML has been widely applied in the field of software engineering [1][2][2][4] and has been standardized by Object Management Group (OMG), which is supported by a large number of tools [8], such as IBM Rational Software Architect (RSA) [17]. Due to the standardization and sufficient tool support of UML, it has been applied in diverse application domains, such as banking, healthcare and communications [1][2]. Object Constraint Language (OCL) is a declarative language to formally specify constraints on UML models, which is also an OMG standard [7]. Combined with OCL, UML can facilitate specification of systems/software in a more precise way. OCL constraints have been widely applied together with UML models to enable model-based testing and consistency checking of UML models [2][4]. Generally speaking, an OCL constraint can be specified for a variety of purposes such as defining constraints on a domain specific language, constraints on a UML profile, and constraints on UML models for a precise definition and to support automation. Comparison with the state-of-the-art software. There are several existing tools for specifying, evaluating and validating OCL constraints such as IBM RSA [17], Papyrus [18], and UML-based Specification Environment (USE) [19]. These tools provide integrated modeling environments to specify constraints in UML models using OCL. Moreover, Eclipse OCL [10] was designed to specify, validate and evaluate OCL constraints and EsOCL [3] was developed to take OCL constraints as input and automatically generate model instances that comply with the OCL constraints using search algorithms. As compared with the existing OCL tools, our iOCL tool poses at least two key differences: 1) iOCL focuses on easing the process of OCL constraint specification by interactively providing guidance, which has a different goal as compared with the existing OCL tools, and 2) iOCL integrates several existing OCL tools and supports their functionalities, i.e., Eclipse OCL and EsOCL. 3. Software framework 3.1. Software architecture The overall architecture of iOCL is presented in Fig. 1, which can be divided into two main parts, i.e., Front End and Back End. The Front End focuses on the interactions with users via a friendly interface. More specifically, the Query Analyzer is designed as an action listener used to: 1) monitor the actions sent from the Back End and 2) communicate with the Front End Controller. The Front End Controller takes charge of the actions and requests from users and dynamically displays the information produced by the Back End (e.g., selection operation or basic value input operation). Furthermore, iOCL defines a set of view templates, which are filled with properties and operations. Filled templates are returned to the users during a particular step during the process of OCL constraint specification. As for the Back End, the core is to handle various requests from the Front End (via Query Analyzer) and return the corresponding output to the Front End dynamically. By doing so, users can be provided with dynamic guidelines for specifying OCL constraints interactively. More specifically, as shown in Fig. 1, the Back End has five key parts, which include: 1) UML Model Reader: imports and parses an UML model, on which OCL constraints can be specified; 2) Constraint Specifier: specifies constraints for particular problems; 3) Constraint Validator: validates specified constraints in terms of syntax; 4) Constraint Evaluator: evaluates the correctness of specified constraints on particular UML model instances. By correctness, we mean there exist one or more valid model instances that can satisfy a specified OCL constraint, i.e., a given OCL constraint may not be correct if we cannot find any valid model instance that can satisfy it. Notice that iOCL analyzes each constraint independently for evaluating the correctness; and 5) Exporter: exports specified OCL constraints into required formats (e.g., .ocl files). Furthermore, as shown in Fig. 1, the Front End is implemented using the external package JavaServer Faces (JSF) [12], which is a well-known Java framework for developing user-friendly interfaces and web applications. The Back End is developed on the top of several external tools Eclipse UML2 [11] (for modeling software systems using UML), Eclipse OCL [10] (for validating and evaluating specified OCL constraints) and EsOCL [2] (for automatically generating model instances
6
M. Hammad et al. / Science of Computer Programming 149 (2017) 3–8
Fig. 1. An overview of the iOCL architecture.
that comply with the specified OCL constraints). Recall that iOCL is a generic web-based application, which can be tried at: http://iocl.zen-tools.com/. 3.2. Software functionalities Recall that iOCL aims to automate the OCL constraint specification process in a maximum manner. The key automation of iOCL is to dynamically shortlist available options at any given step, such that a user can perform the selection user operation in a more efficient way. Therefore, the first key feature (functionality) of iOCL is to systematically check the UML models, the already specified partial OCL constraint, and the current step of the specification process with the aim at providing users only relevant information (e.g., available options to choose) for the next step of specification process. The second key feature of iOCL is to automatically categorize types of constraints, OCL operations, and properties and only display relevant ones at a given step. This feature helps to reduce specification effort and potential syntactic errors that a user often makes when specifying an OCL constraint. Moreover, iOCL also allows a user to roll back to previous steps of a specification process in case there is anything missing. iOCL also automatically takes cares of bracket pairing and automatically fills out left and right brackets thus assisting a modeler with syntax. In addition, as described in Section 3.1, iOCL can evaluate the specified OCL constraints when there is a given UML model instance. When required, iOCL can also automatically generate model instances that satisfy a given set of specified OCL constraints.
M. Hammad et al. / Science of Computer Programming 149 (2017) 3–8
7
4. Empirical results To empirically evaluate iOCL, we have conducted a pilot study by employing a real-world case study from CRN [16], which includes an UML model for capturing the domain knowledge of CRN and 10 medical cancer coding rules. More details related with the domain knowledge of CRN and cancer coding rules can be found in [1]. More specifically, we involved four medical experts from CRN (one manager, two medical coders and one medical programmer) and asked them to specify the given ten cancer coding rules using iOCL. Notice that the selected ten cancer coding rules have not been specified as OCL constraints before. We recorded the time taken by each participant for specifying the OCL constraints and manually checked the syntax validity of the specified constraints afterwards. Notice that it took average 600 s for writing one OCL constraint manually from scratch based on our previous experience working with the medical experts for specifying cancer coding rules using OCL. In addition, more than 50% of the specified constraints were required to be further revised by involving experts for UML and OCL (e.g., the first four authors of the paper). The results of the experiment showed that it took average 259.9 s for each medical expert to specify one OCL constraint using iOCL, which managed to reduce 56.7% time effort as compared with specifying OCL constraints manually from scratch (600 s). We also performed the Wilcoxon Signed Rank test [1] to determine the significance of the results of specifying OCL constraints between using iOCL and without iOCL for specifying OCL constraints. The statistical test results showed that employing iOCL to specify constraints can significantly reduce time of constraint specifications as compared to the way without iOCL. Thus, we can conclude that applying iOCL can significantly reduce the time required for OCL constraint specification in practice due to iOCL’s good capability of providing dynamic guides. Moreover, we observed that all the OCL constraints specified by the four medical experts are 100% valid in terms of the syntax, which do not require additional effort for revising the specified constraints by involving UML/OCL experts. This is due to the fact that iOCL can dynamically assist users by providing valid syntax operations and provides warning/error notifications when the current specified OCL constraint is not valid. Thus, we can conclude that employing iOCL can indeed decrease the possibility of making errors during the specification process. We have also designed pre and post questionnaires with the aim at soliciting the views from the participants (the four medical experts) in terms of the usability of iOCL. The results showed that the medical experts from CRN found iOCL easy to use, which may have great potentials to be applied for specifying the medical cancer coding rules in the current practice of CRN. Notice that one of the key threats to validity is due to the small sample size used to derive conclusions. However, we have involved four real medical experts (as final users) for specifying ten OCL constraints followed by applying appropriate statistical tests for analyzing the results. We agree that more participants should be involved to further increase the sample size but it is worth mentioning we have involved all the medical experts who we are collaborating with at CRN. More details related with the experiment and threats to validity can be found in [16]. 5. Illustrative examples In this section, we illustrate how iOCL can be applied for interactively specifying OCL constraints using the publicly available case study named Royal and Loyal that was designed for the purpose of teaching OCL [13]. Notice that one can download this case study as .ecore file from the iOCL example website (including in total 12 UML classes and 10 OCL constraints). To start with iOCL, one can select an UML model with the format of .uml or .ecore and all of the model elements of a loaded model are automatically displayed in the list, from which one can select one as the contextual element to specify an OCL constraint. One can also select the context from the dropdown Context Selection list. When one selects the context, iOCL automatically displays a list of options such as Invariant, Pre Condition, Post Condition. A user can also roll back to her/his previous selection step via the Back button. When a user selects the context, a list of options is displayed in the Attribute Scope pane. When the user finishes the specification, she/he can click the Validate button to validate the syntactic correctness of the specified constraint and results will be returned to the user immediately. One can also switch from one panel to another, if needed. During the specification process, one can switch to Operation Type panel, which triggers the display of a list of operation types such as Comparison Operation. Last, one can also evaluate the specified constraint based on predefined instances by clicking the Evaluate button. We have created a video to illustrate how to use iOCL, which can be found in: https://www.youtube.com/watch?v=Wgi9YYMp7Q4. iOCL can also help in assessing the correctness of the specified constraint relying on EsOCL [2]. The constraint is correctly specified. If it is solvable, when EsOCL can solve the constraint by providing a valid UML model instance satisfying the constraint. Otherwise, there are two options: 1) EsOCL needs more iterations to solve the specified constraint; or 2) The specified constraint is not solvable. Notice that iOCL can provide users with syntax error information of specified OCL constraints and evaluate their correctness. However, iOCL cannot provide suggested solutions for fixing invalid OCL constraints and this will be investigated as our future work. 6. Conclusion Specifying OCL constraints requires in-depth OCL knowledge from the practitioners and researchers, which is one of the key bottlenecks for applying MBE in practice. To tackle this challenge, we designed an interactive OCL constraint specification tool called iOCL with the aim of assisting users in specifying OCL constraints in an interactive manner. The underlying idea
8
M. Hammad et al. / Science of Computer Programming 149 (2017) 3–8
is to present only the relevant details to a user at a given step of constraint specification process in addition to pre-filling the syntax with the aim of reducing the OCL knowledge required to specify constraints and ultimately reducing the training cost of using OCL. iOCL can also check the syntax of the specified constraints and evaluate their correctness with predefined instances and/or with the automated generated ones. Acknowledgements This work was supported by the MBE-CR (No. 239063) project funded by the RFF Hovedstaden. Tao Yue and Shaukat Ali are also supported by the Zen-Configurator 240024/F20 project, the EU Horizon 2020 project U-Test 645463 (Testing Cyber-Physical Systems under Uncertainty), the MBT4CPS 240013/O70 project and the RCN funded Certus SFI. Shuai Wang is also supported by the RCN funded Certus SFI and COST Action CA15140 (ImAppNIO). References [1] S. Wang, H. Lu, T. Yue, S. Ali, J. Nygård, MBF4CR: a model-based framework for supporting an automated cancer registry system, in: The European Conference on Modelling Foundations and Applications, Springer, 2016, pp. 191–204. [2] H. Lu, T. Yue, S. Ali, L. Zhang, Model-based incremental conformance checking to enable interactive product configuration, Information and Software Technology 72 (2016) 68–89. [3] S. Ali, M.Z. Iqbal, A. Arcuri, L.C. Briand, Generating test data from OCL constraints with search techniques, IEEE Transactions on Software Engineering 39 (2013) 1376–1402. [4] S. Wang, S. Ali, A. Gotlieb, M. Liaaen, A systematic test case selection methodology for product lines: results and insights from an industrial case study, Empirical Software Engineering 21 (4) (2016) 1586–1622. [5] M.Z. Iqbal, S. Ali, T. Yue, L. Briand, Applying UML/MARTE on industrial projects: challenges, experiences, and guidelines, Software & Systems Modeling 14 (2015) 1367–1385. [6] H. Lu, T. Yue, S. Ali, L. Zhang, Nonconformity resolving recommendations for product line configuration, in: International Conference on Software Testing, Verification and Validation, ICST, 2016, pp. 57–68. [7] Object Constraint Language (OCL), http://www.omg.org/spec/OCL/. [8] Unified Modeling Language (UML), http://www.omg.org/spec/UML/2.5/. [9] Eclipse Modeling Framework (EMF), https://eclipse.org/modeling/emf/. [10] Eclipse OCL, http://wiki.eclipse.org/OCL. [11] Eclipse UML2, http://wiki.eclipse.org/MDT-UML2. [12] JavaServer Faces (JSF), http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html. [13] Jcabot/ocl-repository, https://github.com/jcabot/ocl-repository/. [14] M. Hammad, T. Yue, S. Ali, S. Wang, iOCL: an interactive tool for specifying, validating and evaluating OCL constraints, in: ACM/IEEE 19th International Conference on Model Driven Engineering Languages and Systems (MODELS) Tool Demonstration Track, 2016, pp. 24–31. [15] M. Petre, UML in practice, in: 2013 International Conference on Software Engineering, 2013, pp. 722–731. [16] S. Ali, M. Hammad, H. Lu, S. Wang, T. Yue, A pilot experiment to assess interactive OCL specification in a real setting, Technical report (2017-01), available at: https://www.simula.no/publications/pilot-experiment-assess-interactive-ocl-specification-real-setting. [17] Rational Software Architect (RSA), https://www.ibm.com/developerworks/downloads/r/architect/. [18] Papyrus, http://www.eclipse.org/modeling/mdt/papyrus/33. [19] UML-Based Specification Environment, http://useocl.sourceforge.net/w/index.php/The_UML-based_Specification_Environment.