Recently, we have proposed an approach for class modeling starting from imperfect object models. The underlying process puts emphasis on the free expression of ideas of the developer through allowing to formulate incomplete and even inconsistent object diagrams. From these object diagrams, class diagrams are deduced. This paper reports on experiences with a supporting tool grouped into two categories. One category involves students at a university and how they get along with the general concept and the tool. The other category shows how researchers work with our proposed ideas.
To allow for more exibility in modeling, it would be bene cial to have modeling
tools which are not very restrictive with their syntax and in their development
processes. To come closer to diagrams informally sketched on paper with a pencil,
we proposed a lenient modeling approach [
This work is still in development and we try to get as much feedback as possible from potential users to incorporate their ideas. For this reason, we did two studies with two di erent potential user groups. First, we used the tool in a modeling course at university. Since one of the reasons of our work is to reduce the barrier to get started with modeling, it would be interesting to see how people with little modeling experience use our tool. Secondly, the approach should also help experts to sketch their ideas in an informal manner. For this reason, we developed a speci c task for a group of people who already have some experience in the modeling eld. The task included a text in natural language and the experts were asked to use the tool to create an object diagram based on the described circumstances.
The main goal of these two studies is to gather ideas and see how di erent people work with the current state of our tool. This feedback can, and at the time of this writing was already, used for immediate improvements that focus on the needs of potential users. More formal and extensive studies that also test these improvements can then be done in the future.
The structure of the rest of this paper is as follows. Section 2 describes our previous work on this topic. Section 3 describes how the students worked with the tool. Section 4 explains the approach that the experts used to solve their task. Section 5 explains what was learned from our experiments and how it will in uence future work. Finally, a conclusion is given in Sect. 6. 2
The basic idea of our approach is to consider UML object diagrams and extract as much information as possible during an automatic transformation to UML class diagrams. Or formulated more generally: we aim at a transformation from the instance level to the generic level of a model. However, since instances are just speci c scenarios, the general case can not be perfectly described. To ll the gap, we introduced the concept of special markers to highlight where information is still missing <?> or even con icting with other information <!>. We also allow incomplete input on the object side. To highlight optional parts that can be re ned further, e.g. attributes or role names, we use the <+> marker.
An important part of this work is to allow for leniency during the development. The syntax should not force the user to do speci c things, but more resemble drawing diagrams on paper. Because of this approach, there can be inconsistencies and missing information in the diagrams. In Fig. 1 for example, not every role name or association name is written in the \Input object diagram". The \Output class diagram" however shows as much information as possible.
A much more in-depth description of our work can be found in [
In this section, we present two examples created by two di erent students of the modeling course \Design of Information Systems"1. The students had the task to model a system in a context they could choose themselves. To help them achieve that goal, we introduced them to our object to class concept. Our idea 1 http://www.db.informatik.uni-bremen.de/teaching/courses/ss2018_eis/ Input object diagram
Output class diagram bob : Person age father Fatherhood
: Person mother
<+> : Person <+> name='ada' child mother
Motherhood <+> : Person father Person
<?> age name : String child mother
Fatherhood
Motherhood
that modeling may be easier when you start by looking at concrete instances
was thus tested in a practical setting. The complete created diagrams are listed
in [
One student modeled a system for driving schools. The idea is to have a general approach, suitable for cars, planes, and boats. He created two speci c scenarios in the form of object diagrams. The rst one depicts an aviation academy and the second one depicts a driving school for cars. After the transformation, the two resulting class diagrams do not have a lot in common. Out of the 7 classes in the rst diagram and the 6 classes in the second diagram, only three classes are identical. While the attributes of those classes match perfectly, in the one diagram, there is an association between them, while there is none in the other one. The student continued to merge the two automatically created diagrams into one nal class diagram.
Another observation is that the student tried to ll out as much information as possible in the object diagram, while he could have left some parts empty.
The student also wrote a bit of criticism. While the general approach was deemed \a useful method for approaching a universal model", the student did not like the usability of the tool. The main points of negative criticism involve the layout of the diagram and a missing feature for automatic saving. 3.2
Another student modeled a system for a drop zone in the parachuting context. The model revolves around groups of people who enter an aircraft to jump with the help of a parachute. He created two scenarios in the form of two object diagrams. The focus of the rst one lies in the administrative side of the drop zone. It includes aircrafts, their manufacturers and persons working for the drop zone. The second object diagram revolves around an actual jumping process, it includes groups of participating persons. The transformation of these two object diagrams results in two class diagrams. Like in the previous example, the student tried to merge these two diagrams into one large diagram.
After using the plugin, the student also gave some criticism. He said that the way the plugin shows incomplete parts in the form of dashed lines can be hard to see for larger diagrams. He proposed to use di erent colors, like red, instead. He also said that even for small models, like the one in this example, there are already large object diagrams necessary. It would be preferable to allow multiple object diagrams (for sub-scenarios) as input and merge them all into one class diagram during the transformation. He criticized that multiple objects can have the same identi er, for example after cloning an object, and that the plugin allowed that without error messages. Finally, there was some minor criticism that is speci c to the implementation and not to the concept in general. He said that newly created objects are hard to nd in the GUI because they can be covered by other objects. He said the button to delete attributes should only be available when an attribute is selected and that there should be a possibility to delete multiple objects at once. 4
In this section we explain the task that was given to modeling experts and the results. 4.1
The idea was to give a modeling task to experts and see how they handle it with the help of the O2C plugin. A general idea of our procedure can be seen in Fig. 2.
The complete diagrams are listed in [
MODELS 2018 takes place at the \IT University of Copenhagen". This building is in the town of \Copenhagen" in the country of \Denmark".
There are many ways to get to the conference. For example, you can take a plane to get from the building \Toronto Pearson International Airport" in the town of \Toronto" in the country of \Canada" to the building \Copenhagen Airport". This route is 6200km long and costs $500. You can also reach \Copenhagen" by train. If you are in the country \Germany", you can start at the building \Hamburg Railway Station" in the town of \Hamburg" and take a direct train to the building \Copenhagen Railway Station". This Route is 300km long and costs $100.
There are two o cial conference hotel buildings, the \Imperial Copenhagen" and the \Wakeup Copenhagen".
The route from the \Copenhagen Railway Station" to the \Imperial Copenhagen" is 2km long and if you walk, it is also free. The route from the \Copenhagen Railway Station" to the \Wakeup Copenhagen" has the same length and you can walk as well. The route from the \Copenhagen Airport" to the \Imperial Copenhagen" is 10km long and costs $50 if you take a taxi. The route from the \Copenhagen Airport" to the \Wakeup Copenhagen" is 9km long and costs $45 if you take a taxi.
Finally, to reach the conference building from one of these hotels, you can use public transport. The route from the \Imperial Copenhagen" to the \IT University of Copenhagen" is 3km long and costs 3$ with the bus. The route from the \Wakeup Copenhagen" to the \IT University of Copenhagen" is 3km long and costs $3 with the metro.
The participants had to read this text and create an object diagram, based on
this text, with the help of our O2C plugin. After that, they also had to answer
some questions concerning the usability of the plugin, based on the \System
Usability Scale"[
To evaluate what the participants have done, we compared our original object diagram with the diagram that the participants have created. We also compared our original class diagram with the class diagram that gets created by using our automatic transformation, as shown in Fig. 2. 4.2
The rst thing to notice when looking at this solution is that the participant used 5 classes instead of 4. The solution includes an additional \Conference" class instead of an attribute \isConfBuilding" in the \Building" class. The participant utilized the possibilities of the tool to leave role names empty but lled in every association name. Instead of using identi ers for the objects, this participant used anonymous objects. There are also some name di erences for the same concept, like \cost" instead of \price". 4.3
This solution also includes 5 classes instead of 4. The 5th class is also a \Conference" class. There are also no \name" attributes used, this information is moved to the object identi er. The information which vehicle is used is also moved to the object identi er. In some cases, that leads to duplicate identi ers like two \Taxi" objects. The units \$" and \km" are handled di erently. While they are not mentioned in the original object diagram, they are listed by this solution. That also leads to the attributes \distance" and \cost" to be of the type \String" instead of \Integer" after the O2C transformation. This participant completely labeled every association and every role name. 4.4
The rst notable di erence is that, in this solution, there are 3 associations between \Route" and \Building" in the class diagram instead of 2. The reason for that is actually a spelling mistake in the \startBuilding" role name. The 2 https://goo.gl/forms/fiQUwmZUhZsUXRhS2 transformation identi es a new association this way that was not intended. This solution makes use of the functionality to leave parts empty but leaves so many parts empty that there is no association name for some of the associations. This solution also includes the units of length and cost in the attributes, which leads to \String" attributes after the transformation. 4.5
The System Usability Scale (SUS) is a simple, but well proven and valid method
to measure usability [
It has to be noted though that the participation rate was rather low with
only four answers (the three solutions plus one student answer). Even though
the results of the SUS are robust with a small number of participants [
The results from our experiments lead to many topics of discussion. Many of those were only discovered through those experiments and were not clear to us before. The topics range from general discussions about modeling to minor implementation details of the tool. 5.1
Newly identi ed future tasks One of the requested features involves getting help from the already existing class diagram while creating the object diagram. One could, for example, imagine partially labeled links during the creation process, that get their labels from the class side.
One interesting point of discussion is whether multiple object diagrams, explaining di erent scenarios, should be merged into a single class diagram or if there should be one class diagram for each object diagram. The con icting ideas here are, on the one hand, a class diagram should cover a lot of cases. On the other hand, concrete scenarios seem to be a way some people think, so why shouldn't there be a class diagram for di erent cases? The downside, of course, would be that some classes would be in multiple diagrams, but that could be prevented with an appropriate class package architecture.
Something that a lot of participants tended to do was to ll out every possible label for every object and link. Our approach, however, allows leaving redundant parts empty. It might be necessary to better communicate this approach to users of the tool.
Another interesting topic is how to handle the object identi ers. Right now, these identi ers have no in uence on the transformation and therefore the resulting class diagram. This means that right now, it is absolutely allowed to have duplicate object identi ers without any form of error message. This is already not a perfect approach, but once we allow object-valued attributes, it will lead to errors. One could imagine that in the future, the tool detects similar names when doing the merge and asks the modeler if they are meant to be the same.
One thing that became apparent during the experiment with experts, was that there are always multiple possibilities to model a given textual speci cation. For example, some participants used an additional \Conference" class, while in the prepared example, there was an attribute \isConferenceBuilding" that had roughly the same semantic. With future concepts like association classes, there will be similar occurrences where the same concept can be modeled in di erent ways.
Another limitation of UML came into focus during the experiment. When a numerical attribute also has a unit (e.g. price=$12), would that be an attribute of type string? A monetary data item is more than just numbers, so that would probably the best solution.
Known future tasks Some of the proposed ideas by participants were already known to us but were not yet implemented. This includes support for further concepts like association classes, part-whole relationships, and n-ary associations. It would also be good to improve the functionality to allow for object-valued attributes and enumeration-valued attributes.
The order of attributes also has to be addressed in the future. The order on the object side (e.g. rst name and last name next to each other) should be retained on the class side. Right now, the order of the object attributes does not in uence the order of the attributes in the classes. Depending on the input, this is a non-trivial problem, because there may also be con icts within the order. 5.2
There are some issues that do not clearly t into the categories of either general approaches or tool speci c problems. The most important one would be layout. Of course diagram layout is strongly connected to the speci c tool, but it is also a very interesting research topic with many possible approaches.
One participant noticed that it helps to hide parts of the diagram when trying to develop a good layout. This could be the possibility to hide things like role names or association names, but also objects. To not overwhelm users with too many options, there could be an order like only showing association names and only later showing the role names. Another approach could be to not fully hide parts of the diagram, but use a di erent color to grey-out parts and remove them from the main focus. A more radical approach to hide parts would be to work with multiple object diagrams for di erent contexts. This way complete diagrams would be hidden and the user can focus on one speci c context at a time.
Right now we use dashed lines to highlight incomplete objects or links. A participant made the remark that it would be more obvious to use colors like red instead. That was actually done by us in a previous version of the tool but then removed in favor of the dashed lines. This shows that not every implementation detail is favored by all users. Di erent users with di erent expectations, expect di erent implementations. Also, in the interest of not discriminating against individuals who do not perceive the full range of colors (i.e., color blind people), the use of color as a primary di erentiator is discouraged. Furthermore, support for mainstream black and white printouts is most common. 5.3
There was also a lot of feedback regarding the implementation of the tool itself that has little to do with the general concept. We categorized these ideas into the standard software improvement issues \usability improvements" and \bugs". We list these topics in a short way, without much discussion, since the other lessons learned from this chapter are more important and require more space. Usability improvements: (a) The possibility to clone links or at least use existing labels in the same context as suggestions to improve the input process, (b) Aligning objects and classes, a functionality that is possible in the basic USE tool, but not in our plugin, (c) The possibility to edit multiple objects or links at the same time (e.g. selecting multiple objects and when they share an attribute, making it possible to edit all attributes at once), (d) Creating empty link \elements" that can exist on their own and only later connecting them to adjacent objects, (e) More key bindings (e.g. ctrl+c ctrl+v for creating clones and ctrl+x/del for removing elements), (f) The possibility to load .soil les through the GUI, (g) Automatic saving of the object diagram to lower the chance of losing progress, (h) Making it more clear where newly created objects are positioned by somehow highlighting them, and (i) The possibility to delete multiple objects at once.
Bugs: (a) A bug leads to the problem that once a link is destroyed, it always gets destroyed three times, which can also be seen in the soil script, (b) On the object side, it is only possible to save the position of the objects in the layout le. It would be preferable to also save the position of links and their labels. On the class side, the layout saving functionality does not work at all and has to be corrected, (c) The undo/redo function does not work as expected, and (d) The instruction readme le that comes with the plugin is unclear about how loading data from SOIL les works. 6
Our ongoing work on this topic was supported by an evaluation. Both the answers from the students, as well as the answers from the experts led to new ideas about what areas should be improved rst. A major category that became again apparent to us is the need for good layout possibilities. Layout is an important part of understanding diagrams and needs to be given more attention in future work.
Usability is a crucial topic. However, as builders of an academic prototype, it is not our primary focus. We see our task as giving triggers to commercial or open source tool builders once the theoretical work is done. Until then, the features may change frequently and thus we will focus on getting the features done rst and polish the usability later.
We would like to thank Nisha Desai, Khanh-Hoang Doan, Julian Stoick and Moritz Weinig for their fruitful contributions to our work.