Uncertainty is an inherent property of any measure or estimation performed in any physical setting, and therefore it needs to be considered when modeling systems that manage real data. Although several modeling languages permit the representation of measurement uncertainty for describing certain system attributes, these aspects are not normally incorporated into their type systems. Thus, operating with uncertain values and propagating uncertainty are normally cumbersome processes, difficult to achieve at the model level. This work proposes an extension of OCL and UML basic datatypes to incorporate data uncertainty coming from physical measurements or user estimations into the models, along with the set of operations defined for the values of these types.

In this website the complete case studies and software artifacts we reference in our submission are available for download.

Case Studies

1. Train Case Study

This system is composed of people, trains and stations (see figure below). Both persons and trains move towards stations. For simplicity, we assume they all move in one single direction. Monitors observe their movements, and record their last two positions and the time in which they were observed. The speed is automatically calculated from this information, as well as the expected time to arrive at the station. For a person it is also important to know if she will be able to catch her target train, i.e., reach the station at least 3 seconds before the train does.

All these calculations can be specified by means of OCL expressions:

context MovingObject::speed:Real
    derive: (self.current.position-self.previous.position) / (self.current.time-self.previous.time)

context MovingObject::timeToStation: Real
     derive: (self.headsTo.position-self.current.position) / self.speed

context Person::arrivesOnTime:Boolean
     derive: (self.timeToStation + 3) <= self.targetTrain.timeToStation

Note that in practice all these attributes and operations are subject to uncertainty: positions and times are never 100% precise, and this imprecision is propagated to derived values and estimated times. For example, suppose our positioning system is correct up to one centimeter, and our clock has a precision of 1 second. This can be captured in our model by types UReal and UBoolean, respectively, which extend basic types Real and Boolean with measurement uncertainty, and permit expressing and propagating through the types' operations the associated uncertainty.

This case study was originally described in [1], and it has been fully implemented in the USE tool [2], which has been properly extended to include our uncertain types as basic types and collections. Both implementations of our case study (with and without uncertainty) can be downloaded from here.

2. Ozobot

This system is a robot, in particular, an Ozobot robot that is able to move in the direction its head points to. These kinds of robots accept two type of commands: one to rotate its head at a certain angle, and another one to move forward some distance. When both commands are combined, the rotation is executed first.

To assign a Mission to a Robot, we need to define a plan, which is a sequence of commands (rotations and movements). Each mission determines the target position the robot is supposed to reach after performing the plan. Positions are given by coordinates in a planar surface (i.e, they are points in a plane that represents the floor).

With our approach, we are able to analyze a robot's behavior and check whether the sequence of movements defined in its plan fulfills the mission, i.e., reaches the target position.

The class Robot offers the operation performAllMoves() that goes through all the movements in its plan, and performs them in sequence. Every movement calculates the target coordinate after the move, and requests the robot to advance to that position. In order to check whether the robot has reached the final target position, the class Coordinate provides the operation coincide() that determines whether two coordinates are equal.

All operations on attributes are performed using the enriched type system, thus they transparently take into account uncertainty. The result is an UBoolean value that returns true or false and the confidence on that value.

3. Robot Battle Case Study

This system is inspired in Ozobot robots (presented before). In this case, the system represents a battle between robots and other unidentified objects in a planar surface. Robots are in charge of ensuring that no unidentified object gets close to the area they protect.

The robots are tasked with ensuring that no 'unidentified object' gets close to the area they protect. The position of each object is specified by a pair of coordinates, x and y, and the object moves in the direction that is dictated by its angle attribute (expressed in radians) with a specified speed (in m/s). The size of each moving object is determined by its diameter (attribute width, also in meters).

The dynamics of the system, i.e., the movements the objects perform, are carried out via the operation move(), which updates the coordinates of the object based on its current angle and speed and the number of elapsed seconds since the last movement. Times are expressed using the POSIX time convention, i.e., by the number of seconds since January 1, 1970.

If a robot detects that an unidentified object is moving at a speed that exceeds 0.3 m/s and gets close to its position, the robot identifies it as a threat and marks it. The mark is represented by an object of class Mark, whose coordinates coincide with the position of the marking robot. Every time the operation shootAtMarkedThreats() is fired, the robot shoots at all objects that have been marked as threats with a probability greater than 0.9.

We have used variables of types UReal, UBoolean, UInteger, and UString in the metamodel of the system and in some of the OCL expressions, thereby making use of the new types that we have defined in [3] as extensions of the OCL/UML basic datatypes. From a modeler's perspective, they do not represent much of a change compared to the specifications that would have been written using the standard UML and OCL basic datatypes. Nevertheless, the use of these new types enables representation and operation with the associated measurement uncertainty that these attributes may have since they represent real-world quantities. For example, attributes width, angle and speed may be imprecise due to the tolerance or inaccuracy of the measurement instruments. Similarly, attribute hitsTarget is of type uncertain Boolean because the shooting instruments may also be imprecise, which may cause the bullet to miss the target. In contrast, the attribute id of a robot is of type String, whereas the identifier of an unidentified object is of type UString because it can be subject to uncertainty due to insufficient quality of the reading instruments or lack of visibility. Due to this uncertainty, a robot with an identifier that is not clearly visible can be considered as unidentified object and, hence, shot at.

This case study is fully described in [3], and can be downloaded from here.

4. Mechanical Arm Case Study

This system models a production line that classifies apples. It is composed of mechanical arms. Each arm is associated to a tray with apples, and has a sensor that measures color and returns the amount of red, yellow and green present in the apple skin and classifies it as follows:

  • RedDelicious: the color contains more than 90% red
  • PinkLady: 40% red or more, and less than 10% green
  • GoldenDelicious: more than an 80% of yellow
  • GrannySmith: more than 70% green
  • Cooking: otherwise

The arm has a base position where it waits to be signaled that there is an apple and then, it grabs it from the tray and classifies it. Once classified, the arm moves to the corresponding container where the apples of that type are stored, and drops it. Finally, it moves back to its base position where it waits for more apples to arrive. Every time that the arm goes back to its base, its position is reset to the position of the base, which is known with precision.

Attribute tolerance indicates the arm position accuracy. Normally this parameter is not constant in any mechanical device; on the contrary, it increases with the use: every time the arm performs a movement--either from its base position to the tray, from the tray to a container, or from a container back to its base position--the slack of its gears and mechanisms slightly increases, producing a progressive degradation of the arm position accuracy. Attribute deterioration records this value, which is normally provided by the manufacturer. Although it is usually a very small value, it can significantly accumulate by repeated use. The deterioration value is added to the arm's tolerance with every movement.

Due to this accumulated lack of accuracy, the arm may miss an apple when trying to fetch it. Similarly, it may miss the container when dropping the classified apple. These misses are captured by attributes missedApples and wastedApples, respectively. Of course, the tolerance and deterioration, and hence the amount of missed and wasted apples depends on the quality of the arm.

Finally, the arm can be calibrated by the manufacturer when its position accuracy becomes very low. For instance, when the tolerance becomes 10 times higher than the deterioration, its attribute needsCalibration may become true, warning the workers in the plant that the arm needs to be sent to the manufacturer for calibration.

Note the use of uncertain types in some of the attributes, and in particular the use of uncertain enumerations (UColor) to represent the fact that a variable may take some of the enumeration literals, each one with a given confidence.

This case study is fully described in [3], and can be downloaded from here.

5. Traffic Control Case Study

The traffic control system models a SPECS average speed camera system for one-way tunnels. In the tunnels, there is one camera at its entrance and another at its exit. Each time the system detects a movement at the entrance, the corresponding camera takes a picture and creates a report. In the same way, when a movement is detected at the end of the tunnel, the exit camera takes a picture. The pictures are processed by an automatic number plate recognition (ANPR) system and the text is stored in a UString value, with the confidence associated to it. This is a typical use of an uncertain String, given that the OCR device may have problems identifying the correct characters that comprise the String, due to lack of precision in the picture taken in case of foggy or stormy days.

The traffic control system checks whether, for every exit picture, there is a report open with the same number plate and with a confidence higher than 0.8. If so, the pictures and report are related and the information about the average speed is computed. Traffic regulations state that a vehicle should be fined if its average speed is higher than the maximum speed allowed in the tunnel. Therefore, if the attribute 'fined' in the Report states with a confidence higher than 0.85 that the vehicle should be fined, an instance of the class Fine is created, with a penalty of 500 if the speed exceeded the limit by less than 30 km/h, or 800 otherwise.

The figure below shows an object diagram, in which the entry camera took a picture of a plate with number '1243ABC', with a confidence of 0.9, entering the tunnel at time 153 ± 4.0, and the exit camera took another of number plate '1243ABC' with confidence 0.9 leaving the tunnel at 159.0 ± 4.0. (Although a confidence value of 0.9 is quite low and unusual, it may occur due to restricted visibility on foggy days, for instance.) Our system detected that these two plates belong to the same vehicle with a confidence of 0.810. Since the confidence exceeds 0.8, our system assumes that both plates belong to the same vehicle and, for them, a report has been created that indicates that the average speed was 83.33 ± 5.66. The probability that this speed exceeds 80 km/h is 0.72 (72\%). Since this probability is lower than 0.85, the vehicle is not fined; therefore, the Fine object is not created.

This case study is fully described in [3], and can be downloaded from here.

6. Smart Home

This is an example of run-time models taken from the Complex Event Processing (CEP) domain. This system simulates a smart house, with sensors that permit detecting three basic parameters: temperature, carbon monoxide (CO) level, and whether the main door is open or not. These values are periodically sensed and notified by means of events, as well as the position of the people living in the house. The classes Person and Home represent the CEP simple events while the classes shaded with darker background color represent the complex events defined by the application.

Since the sensors may provide measure that are not precice but contain certain degree of uncertainty, this uncertainty is captured in our model and reflected in its behavior, which is:
  • A TempIncr object is created every time the temperature of the house has increased 2 or more degrees in less than one minute.
  • A TempWarning object is created when four TempIncr events are detected in less than 5 minutes, while temperature remains above 33 degrees.
  • A COHigh object is created each time the CO levels exceed 5000 units.
  • A FireWarning object is created if a COHigh event is detected, followed by a TempWarning event within less than 5 seconds.
  • A NobodyHome object is created if the main door of the house is closed and there is no person within the perimeter of the house.
  • A Call object is created if a FireWarning occurs after a NobodyHome object is created.

7. Robot ML

In this example, we have chosen RobotML, a dedicated language for designing robotic applications implemented in Papyrus (i.e., RobotML is a domain-specific language based on UML).

The language metamodel contains approximately 80 classes and 75 attributes. It is divided into different subtypes of systems, e.g., in SensorSystems and ActuatorSystems, which are further refined into more concrete types of sensors and actuators.

Here, excerpts of the redefined metamodel using our approach for modeling uncertainty are shown. For the complete implementation of the case study using our library in MagicDraw, we refer the reader to our Git repository.

8. Robot DSL

F. Ciccozzi et al. defined a family of domain-specific languages [4] for the specification of civilian missions of mobile multi-robot systems and showed how they applied it in two real-world application domains. Unfortunately, these languages does not consider uncertainty.

We have extended the specification of this family of languages with our MagicDraw library. For illustration purposes, we present here some of the UML diagrams. For the complete implementation of the case study, we refer the reader to our Git repository.


The OCL/UML, Java and MagicDraw libraries with the specification and implementation of the uncertain datatypes and their operations, and the case studies are available from our Git repository.

The extended version of USE which includes uncertain datatypes as primitive types can be downloaded from here.


[1] Manuel F. Bertoa, Nathalie Moreno, Gala Barquero, Loli Burgueño, Javier Troya, and Antonio Vallecillo: "Expressing Measurement Uncertainty in OCL/UML Datatypes". In Proc. of ECMFA 2018, LNCS, Springer 2018. (PDF)
[2] Gogolla, M., Büttner, F., Richters, M.: "USE: A UML-based specification environment for validating UML and OCL." Sci. Comp. Prog. 69 (2007) 27-34
[3] Manuel F. Bertoa, Nathalie Moreno, Loli Burgueño, and Antonio Vallecillo: "Incorporating Uncertainty into OCL/UML Datatypes". 2018. Extended version of [1], currently under review. (Technical Report)
[4] Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, and Patrizio Pelliccione. 2016. Adopting MDE for Specifying and Executing Civilian Missions of Mobile Multi-Robot Systems. IEEE Access 4 (2016), 6451–6466.