Measurement uncertainty, an essential property of any physical system, is gaining attention in the modeling community due to the need to specify these kinds of system properties. Some notations already provide support for representing this information, but there is also the need to count on tools with native support for datatypes enriched with measurement uncertainty, able to manage it in a natural and transparent manner. This paper describes the extension that we have developed for the tool UML-based Specification Environment (USE) for supporting the primitive UML/OCL datatypes with uncertainty information.
Physical systems operating in the real world are always subject to uncertainty.
In most of the cases, measurement uncertainty [
In previous works [
In [
The rest of the paper is structured as follows. Sect. 2 explains the related concepts to uncertainty in UML/OCL datatypes and the tool USE, and Sect. 3 details the technical details of the implementation in USE. Finally, Sect. 4 presents our conclusions and outlines future work. 2 2.1
In [
Then, for extending a primitive OCL datatype <T>, we defined an embedding into a supertype U<T> that incorporates information about the uncertainty in the values of <T> and defines the operations for the extended type, which are also applicable to the base type.
The uncertainty information, both its meaning and the way in which it is
propagated, varies depending on whether the values of the base type are numbers,
Booleans or Strings. For example, UBoolean values are pairs (b, c), where b is
a Boolean value and c is a Real number in the range [0; 1] that represents the
confidence in b; while a UReal number is a pair (x, u) where x is a Real number
and u is its standard uncertainty as stated by the ISO Guide to the Expression
of Uncertainty in Measurement (GUM) [
The subtyping (<:) and embedding (,→) relationships considering both the standard and the extended datatypes are as follows:
→, →, →,
Boolean
→, UBoolean
String
→, UString
The example in Fig. 1 shows a model, taken from [
Class diagram
Robot * robot position : Coordinate headsTo : UReal performAllMoves() 1 robot
Target 1 target position : Coordinate Mission
Plan Movement
move : UReal * moves {ordered} rotate : UReal performMove()
Coordinate x : UReal y : UReal coincide(c : Coordinate) : UBoolean distance(c : Coordinate) : UReal
Interestingly, the behavior of the system with uncertainty uncovers the fact that the precision of the robots movements has a significant impact on their plans, since it accumulates very soon and therefore the missions easily fail. Therefore the importance to have measurement uncertainty into account when modeling a system that deals with physical quantities; otherwise the models do not provide faithful descriptions of the systems they try to represent. 2.2
USE [
USE provides mechanisms for the extension with new functionality by means of user-defined Ruby functions (placed in files under the folder oclextensions). All code available in this folder is loaded when USE is opened.
This extension mechanism enables the definition of new operations (and their
behavior) for the predefined datatypes, but it does not allow the creation of new
datatypes. In order to add new datatypes, the USE source code has to be forked
and its native implementation has to be modified, which is what we did as a
proof of concept in our previous work [
Internally, the USE tool uses ANTLR to define the grammars that it
supports (for USE class models, OCL, SOIL [
Despite its graphical interface, the specification of models in USE is textual. Thus, the first step when adding new functionality to the tool is to update the grammar of its languages. In our case, we had to modify its OCL grammar which is located in its base file org.tzi.use.parser.base.OCLBase.gpart. Listing 1.2 shows the part of the grammar that we modified. In particular, we added the code in lines 7–18 and the new rule in lines 20–22.
Listing 1.2. Extended USE grammar. 1 literal returns [ ASTExpression n ] : 2 t=' true ' { $n = new A S T B o o l e a n L i t e r a l ( true ) ; } 3 | f=' false ' { $n = new A S T B o o l e a n L i t e r a l ( false ) ; } 4 | i=INT { $n = new A S T I n t e g e r L i t e r a l ( $i ) ; } 5 | r=REAL { $n = new ASTRealLiteral ( $r ) ; } 6 | s=STRING { $n = new A ST S tr i ng L it e ra l ( $s ) ; } 7 | ' UString ' LPAREN usve=a d d i t i v e E x p r e s s i o n COMMA 8 usue=a d d i t i v e E x p r e s s i o n RPAREN 9 { $n = new A S T U S t r i n g L i t e r a l ( $usve . n , $usue . n ) ; } 10 | ' UReal ' LPAREN urve=a d d i t i v e E x p r e s s i o n COMMA 11 urue=a d d i t i v e E x p r e s s i o n RPAREN 12 { $n = new AST URealL itera l ( $urve . n , $urue . n ) ; } 13 | ' UBoolean ' LPAREN ubve=c o n d i t i o n a l I m p l i e s E x p r e s s i o n COMMA 14 ubpe=a d d i t i v e E x p r e s s i o n RPAREN 15 { $n = new A S T U B o o l e a n L i t e r a l ( $ubve . n , $ubpe . n ) ; } 16 | ' UInteger ' LPAREN uive=a d d i t i v e E x p r e s s i o n COMMA 17 uiue=a d d i t i v e E x p r e s s i o n RPAREN 18 { $n = new A S T U I n t e g e r L i t e r a l ( $uive . n , $uiue . n ) ; } 19 . . . ; 20 unc ertai ntyTyp e returns [ ASTType n ] : 21 name=(' UReal ' | ' UInteger ' | ' UBoolean ' | ' UString ' ) 22 { $n = new ASTSimpleType ( $name ) ; } ;
Then, using the ANTLR tools, the Java lexer, parser, tokens and listeners were automatically generated.
The implementation of datatypes in USE is done in a modular way. It distinguishes between values and expressions, both of which have a type. Accordingly, the Java source code that implements the datatypes is structured in three packages, namely, org.tzi.use.uml.ocl.type, org.tzi.use.uml.ocl.value, and org.tzi.use.uml.ocl.expr, which is shown in the top part of Fig. 2. The package at the bottom, called atenearesearchgroup.uncertainty.uDatatypes contains the Java library that we have developed with the behavior of the types UUnlimitedNatural, UInteger, UReal, UBoolean and UString, which is used by the other three packages.
The content of the extended USE package org.tzi.use.uml.ocl.type is displayed in Fig. 3. The elements in white are the USE original classes, whilst the interfaces and the elements shaded in gray are the new classes that we have added. We created an abstract class called UncertainType from where all the uncertain types inherit. Each class defining a type contains the constructor of the type and the OCL methods for type checking. For instance, the class UReal contains its constructor and methods such as isTypeOfUReal, isKindOfUReal, isKindOfNumber and isKindOfOclAny. We have also modified the original USE classes to add the operations that allow the identification of the new datatypes as their supertypes of the original datatypes, when applicable. For instance, we have added to the class RealType the methods isTypeOfUReal() and isKindOfUReal().
The package org.tzi.use.uml.ocl.value contains a similar hierarchy of
elements, as Fig. 4 shows. This package uses the Java library that implements
the behavior of the uncertain datatypes [
The new classes that we have created in USE implement the Adapter
design pattern [
Finally, once the types and value of the new datatypes were created, the last step was to make them available for their use inside OCL expressions and make their operations available, too. Regarding the latter, we decided to overload the existing operators such as “+”. Then, a user can perform the operation “+” with any numeric parameter independently whether it is uncertain or not.
In USE, this is implemented in the package org.tzi.use.uml.ocl.expr, which contains a class for each datatype. Then, for each uncertain datatype, we have created a new class with the following signature: StandardOperations<T> where <T> is the name of the new datatype—for instance, StandardOperationsUBoolean. Furthermore, we had to register all the operations in the USE class OpGeneric.
Regarding the operations on collections, we distinguish between those which return a boolean value (such as forAll, exists and includes) and those which return objects (such as select, any and count). The former operations are overloaded and only when they contain uncertain values, they return a UBoolean—in the rest of the cases, they stick to their original behavior and return a Boolean value. For the latter operations, we decided to create new versions of them with the prefix “u” for dealing with uncertain values—for instance, uSelect. Each operation is defined in a Java class that inherits from ExpQuery.
Finally, we followed a test-driven methodology when extending use. Thus, we extensively used the testing facilities that USE provides for unit and system testing. Following the same folder structure and style in which all the tests were developed, we included our tests under the folder src/test. We created new test classes for the new functionality that checked both its grammar and its behavior—, and executed them in batch using ANT.
We have presented an extension of the tool USE to enable the application of native uncertain types for capturing measurement uncertainty, and we have shown how we structured and implemented the extension. Although the aim of this work was to extend the UML/OCL primitive datatypes that are supported by USE with our library of uncertain types, the same approach could be used to extend other UML/OCL tools, if they have an internal organization for supporting the datatypes. Our uncertainty extension has been already applied in several middle-sized models — see, e.g., http://bit.ly/UncertainContracts-Examples.
There are several lines of research that we plan to address soon. First, we would like to check and improve (if needed) the efficiency of the execution of operations and to extend the evaluation browser with aspects of uncertainty. We also plan to check how far other OCL evaluators can be extended in this way, and study the effort required to do so.
Acknowledgements. We would like to thank the reviewers for their constructive comments on previous versions of this paper. This work has been partially supported by Spanish Research Projects PGC2018-094905-B-I00 and TIN201675944-R.