We demonstrate the use of the textual modeling language called Umple on a software modeling challenge problem that requires participants to create an executable model of a robotic rover that must follow another rover at a safe distance. We used a wide variety of features of Umple in the solution, including class models, state machines, aspects, and mixsets (feature models). We implemented two separate solutions to the problem. Our first solution, in which pulses of full power of varying lengths alternate with direction changes, performs significantly better than our second solution in which power and direction are blended together and varied in amplitude. Overall Umple proved very versatile at exploring various dimensions of this problem.
In this paper we present a solution, written in Umple, to the MDETools 2018 workshop
challenge problem [
Our solution involved static and dynamic modeling. The static model was a class model of the two types of rovers, with various attributes and associations. For the dynamic part of the problem – autonomous following – we used two distinct models. The first we call ‘frequency modulation’. It involves applying pulses of 100% forward thrust to both sides, as well as turning pulses (one side 100% forward, the other side 100% reverse). The pulses are varied in duration (and hence frequency), with longer pulses being needed when greater corrective action is needed. This mimics the way a human might manually operate the follower rover; indeed it was inspired by spending time using a manual interface provided by the workshop organizers.
The second approach we call ‘amplitude modulation’. It uses a state machine that adjusts the power of left side and right side wheels at regular intervals. The amount of power applied is varied depending on the need for corrective action. Similarly, the greater the need for turning, the greater the difference between power applied to left and right wheels.
While it was easy to tune the system to give good following results for the frequency modulation approach, we were not able to effectively tune the amplitude modulation approach. The main lessons from this paper are, however, the effectiveness of Umple for modeling the problem and developing the solution. Umple features such as state machines, mixsets, its dual textual-diagram nature, and the detailed feedback it gave to point out model weaknesses all facilitated rapid development of our solution.
In the next section we give an overview of Umple. Following that, we give a detailed narrative of the steps we followed to develop the solutions, and our lessons learned. 2!
Umple [
Umple’s features are described in its 530-page user manual [
Although it can be made to ‘play nicely’ with models and tools that are part of the Eclipse/Papyrus/EMF ecosystem, it does not by design have any dependencies on that ecosystem.
In the remainder of the paper we will present and explain a few snippets of Umple
as we illustrate the work we performed on the challenge problem. The reader is invited
to view our repository [
We followed an agile approach to developing our solutions. This involved small iterations with testing and re-planning after each iteration.
Each iteration is outlined in this section. We have documented in detail the process
we followed to help others understand experiences in using Umple, and to allow
comparison of tools. The resulting code, at various stages has been placed in a Github
repository umple/roverChallenge [
We created the first version of our system in the following three sub-steps:
provided (manual-controller) version of the challenge problem [
The provided application also comes with a configuration file allowing changing various parameters, such as how erratic the leader should be in terms of speed and changes of direction. Although we experimented informally with adjusting these parameters, we elected to leave them exactly as they were provided for the remainder of our work. This will allow other models to be compared to ours more easily.
We encountered some initial obstacles getting the provided setup working on our Macintosh. However these turned out to be caused by omissions in the instructions for manually controlling the follower, and were fixed after consulting the organizers.
After getting the manual controller working, we spent approximately 30 minutes controlling the follower manually in order to better understand the behavior of the leader and strategize about how we would model an autonomous follower. Manual control using the provided interface involves pressing the ‘up arrow’ key to apply full power to the wheels; releasing the key causes the rover to ‘coast’ over the simulated gravel environment. We found that the best way to cause the follower rover to maintain an optimal distance from the leader is to pulse the power by pressing the key for short intervals (about once a second for half a second), but more often and for longer if the follower rover falls behind, and ceasing the pulses if the follower gets too close. Manual control for steering is by pressing the left or right arrow keys; this causes full power to be applied to the wheels on one side (e.g. left to turn right) and full reverse power to be applied to the opposite set of wheels. We found that pulsing this power by pressing these keys for brief intervals, between forward pulsing, best enables course correction. These observations became the basis for our Frequency Modulation solution discussed in Section 3.2 below.
We committed the original version of the code to our repository [
process recommended for many adopters of Umple that are faced with an existing code
base. It involves taking code written in a language such as Java and converting it into
Umple. This allows developers of legacy software to gradually and painlessly convert
their code so that it becomes model-based, all the while making sure tests pass at every
stage. The ‘Umplificator’ tool [
The provided manual controller code consists of three files. SocketCommunicator.java, DriveCommands.java and RoverController.java. We elected to initially only umplify the third of these, and leave the others as ‘external libraries’, in order to demonstrate an important feature of Umple: interoperation with other tools, in this case plain Java. The umplification of RoverController.java was a one-minute process, since the Umple compiler accepts Java syntax in almost as-is. The result was a file called RoverController.ump. We simply had to convert Java ‘import’ statements into Umple ‘depend’ statements and declare the other two files as external Java classes using Umple’s ‘external’ keyword. We then used the manual rover controller user interface, described above, to verify that the resulting program (compiled now by Umple) behaved in the same way as the originally-provided program.
We used the command-line version of the Umple compiler for this work, as well as UmpleOnline for working with diagrammatic views of the models.
involved stripping all the manual control logic, including the user interface that accepted keystrokes, from the system. Control of the rover was replaced by a single short method called ‘follow()’ that simply drives straight, makes a turn and drives straight again. In other words it does not actually pay any attention to the leader, but was written to ensure that the system still could be compiled and executed.
It is worth noting at this stage that although the RoverController class is written in Umple, it is still not at this stage using any of Umple’s modeling capabilities. The follow() method is just plain Java. One of the key features of Umple is that plain Java can be embedded in Umple. However a diagram can nonetheless be drawn of the system by Umple, and this appears in Figure 1.
The end-result of this step was committed to the repository [
Our next step was to start altering the Umple model to enable autonomous control. In the RoverController.ump file, we defined an abstract Rover class that has attributes and methods common to the leader and follower. We added subclasses for the latter two. Implementations of methods allow instances of these classes to be updated with current information about their position by querying the connected servers. Of particularinterest is a method that computes the bearing from the follower to the leader, enabling it to know what course it must optimally follow. This is line 151 in RoverController.ump and is as follows: bearingToLeader= Math.toDegrees(Math.atan2(leader.getXPosQuick() - getXPosQuick(),leader.getYPosQuick() - getYPosQuick()));
Central to the following approaches we present later is turning the rover such that the bearingToLeader is within 5 degrees of the follower’s compass heading. 1 2 3 4 5 6 7 8 9 10 11 12 13 } class Rover { abstract; String nameForCommanding; SocketCommunicator querySocket; long lastUpdateTime = 0L; * -> 1 RoverController controller; // association Double xPos = 0.0;
before getXPos {updatePosition();} // get from server Double xPosQuick = {xPos}; // get from cache Double yPos = 0.0;
before getYPos {updatePosition();} Double yPosQuick = {Pos};
Figure 2 is a class diagram generated by Umple. Figure 3 is a sample of Umple text describing the Rover class. Some features of Figure 3 are worth pointing out: •! Line 2 has the keyword ‘abstract’ this is Umple’s syntax to declare a class as abstract.
We call such keywords ‘stereotypes’ following UML conventions. •! Lines 3,4,5,7 and 10 define various attributes. They are like variable declarations but have more sophisticated semantics, aligning with UML conventions, but also allowing ‘aspects’ to systematically adjust their generated code. •! Lines 8 and 11 are simple aspects that ensure that before accessing the data, it is updated from the server. •! Lines 9 and 12 allow bypassing this update, if the developer knows it has recently been performed.
After tuning, we were able to ensure that follower follows the leader in all circumstances, but it errs on the side of following too far (following too close can lead to crashes). Table 1 shows that version 2 of the follower on average manages to stay in the required zone 53.2% of the time when tested with the provided testing module UnityObserver.jar. Version 2 of the RoverController jar is available in our repository.
step was to refactor and improve the Umple model. Unlike Java and many other languages, Umple does not force the user to keep one class per file. In fact, a typical Umple model would have a several-to-several relationship between files and class fragments. Files in Umple should be seen as units of human-understandable functionality. Umple’s ability to distribute class fragments among multiple files might hypothetically make it hard to find needed code or model elements. However in practice, we have found this is not an issue: Javadoc generated from Umple helps the user locate the needed elements, as do diagrams generated by Umple and simple searching.
Figure 4 presents the File model for distribution of functionality after refactoring. We left the pure Umple class model into RoverController.ump. We moved utility logic such as code that obtains data from servers and calculates values such as bearings to RoverController_code-updateData.ump, and the follow() method to RoverController_FMfollow.ump. We also extracted hard-coded parameters needed for the control algorithm to RoverController_FMparameterSets.ump.
As a final step to create version 2a of our controller, we experimented with changing values of key algorithm parameters. In particular we had originally decided to allow the lower bound for the time-period of power pulses, and also the coasting period between pulses, to be 500 ms, mimicking our manual control method discussed in Section 3.1. To make the controller more responsive we reduced this to 250ms. Table 1 shows this resulted in much better in-zone following performance. We tried to reduce these parameters to be 125ms, or other values between 125 and 250ms, however we ran into problems: Messages sent to the simulation and the RoverController were sometimes taking more than 125ms for the round trip (message sends plus processing), and this led to erratic behavior. This is classic deadline-miss behavior common in real-time systems. We settled on 250ms as the shortest time that resulted in stable behavior. For version 3, we attempted to create a totally different algorithm. Whereas in version 2, we had pulsed full power for varying amounts of time, with full 100%/-100% power application for direction changes if needed. In version 3, we tried instead adjusting power at values less than 100%. We also attempted to turn by varying the power to left and right wheels – with greater difference when more turning is needed.
This was achieved by using a pair of state machines to control distance and direction. The diagram for the latter appears in Figure 5, and the Umple code appears in Figure 6. Full details are in the repository. Textual state machines in Umple can be identified as a state machine name followed by a brace, so line 2 of Figure 6 marks the start of a state machine. Line 3 marks the start of a state. Line 5 indicates an action to take on entry to the state. Line 6 specifies a guarded transition, with the guard in square brackets, and the target state appearing after the -> symbol. The words in all-caps are tuning parameters that can be adjusted in the file RoverController_AMparameterSets.ump.
Although we spent much time trying to fine-tune the parameters for this AM approach, we were never able to get it to perform as well as the FM approach.
We have nonetheless left the AM approach in the code base, but have switched it off by commenting out the mixset (feature) that activates it in the feature model. A user running version 3 of our system will achieve the same results as for version 2a unless they uncomment RoverController.ump line 22 and comment out line 21.
Results of executing the Amplitude Modulation solution are found in Table 2. We wrote 732 lines of Umple model/code. Generated Java was about double that. We did not find any bugs in Umple in this project, and were able to complete it in a day.
Some Umple features that proved particularly useful were the following: •! The Umple compiler’s error messages were precise and allowed us to rapidly solve the few syntax or semantics errors we made. It usually just took minutes from the time of completion of writing any update of the model/code to the time when we were able to get the new version running. The majority of development time was spent strategizing about the model, tuning model parameters, and running the simulation. Debugging of Umple or embedded Java was less than 5% of total time spent. •! It was nice to be able to see both textual and graphical views of the model, as they were able to serve as quality checks on each other. •! Embedding of algorithmic code (as needed for calculations) in the model helped simplify development. These were added as derived attributes, state machine actions, and ordinary methods. •! Injection of code into generated methods, such as to load data from the server and send control messages, using Umple’s ‘before’ and ‘after’ constructs, proved very useful and effective. •! Umple’s mixset capability, allowing alternative versions (AM and FM agorithms) of our product line served well in the solution to this problem.
The ‘FM’ version of the solution, using pulses of full power, worked better than the ‘AM’ version, that varied power amplitude. The software that was provided for the challenge did not facilitate the automation of parameter tuning because each run would take several minutes. Nonetheless, we were able to develop a solution by manually adjusting parameters that kept the follower at the desired distance 65.5% of the time.
From the perspective of the authors, Umple’s features discussed in the last section made it both useful and easy to use for this project. They allowed us to effectively solve the core modeling problem, which was to enable a rover to autonomously follow another.
We tried two dynamic autonomy models. The one that worked best involved pulsing power to the wheels. We suspect this is because the follower needs to apply full power much of the time in order to keep up with the leader, and perhaps because pulsing might help prevent skidding, in the same manner as pulsing car brakes stops skidding.
As future work it would be nice to instrument the simulation so the parameters can be learned via machine learning. Many variations of the model could also be tried.