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

Train Case Study

The case study described in [1] 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.

The system used as a case study 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, however, 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 such uncertainty.

Robot Battle Case Study

This case study has been prepared for our work [3] (under review). Its implementation in USE can be downloaded from here.

This 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 dynamics of the system, i.e., the movements the objects performs, are carried out by the operation move(), which updates the coordinates based on its current angle, speed, and the number of elapsed seconds since the last movement. If a robot detects that, at a certain moment, an unidentified object is moving towards it at a speed higher than 0.3 m/s and it's no futher than 10 meters, the robot identifies it as a threat, and marks it by creating an instance of the class Mark. 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.

Mechanical Arm Case Study

This case study has been prepared for our work [3] (under review). Its implementation in USE can be downloaded from here.

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.

Traffic Control Case Study

This case study has been prepared for our work [3] (under review). Its implementation in USE can be downloaded from here.

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.

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 Java and OCL/UML specifications of the uncertain types and operations as well as their implementations are available from our Git repository Git repository under moliz.quantitytypes/plugins/org.modelexecution.quantitytypes.java/.

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.
[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. Under review.