-The specification of any non-trivial system is normally composed of a set of models. Each model describes a different view of the system, focuses on a particular set of concerns, and uses its own notation. For example, UML defines a set of diagrams for modelling the structure and behavior of any software system. One of the problems we perceived with our students is that they are able to understand each one of these diagrams, but they have problems understanding how they are related, and how the overall system specifications work when composed of a set of views. This paper presents a simple case study that we have developed and successfully used in class, which permits students developing the principal views of a system, simulate them, and check their relations.
I. INTRODUCTION
Non-trivial systems specifications need to be decomposed in various models (views), each one focusing on a particular set of concerns and described in a particular notation. For example, UML defines a set of diagrams for modelling a system that permit describing its structure (class diagrams), the behavior of its individual objects (state machines), the collective behavior of collections of objects (communication and sequence diagrams), etc. There are two main problems that we have perceived with our students when teaching the use of models. First, they normally tend to see models as drawings, mostly used for communication among humans, and not as software artefacts that need to be processed by computers. Hence they tend to be less precise and formal than when developing programs. And second, when dealing with multiviewpoint models, students may be able to understand each one of these diagrams, but they have problems understanding how they are related, and how the overall system specifications actually work when composed of a set of views.
This paper presents a simple case study that we have
developed and successfully used in class, which permits students
to develop the principal views of a system, simulate them,
and understand their relationships. We use a combination
of UML and OCL and the possibilities that the OCL/USE
tool [
The example we present here—originally defined in [
The rest of the paper is structured as follows. The next
Sect. II describes the example and shows interesting properties
using the USE modeling environment [
II. A UML AND OCL MODEL FOR A PRODUCTION LINE
SYSTEM
Let us illustrate our approach by modeling a plant that produces hammers. This plant is composed of four machines: one that generates hammer heads, another that generates handles, one that assembles heads and handles, and finally one that polishes the hammers. There are also trays that are used to collect the goods in production.
The plant operates as follows: each generating machine has an associated tray, in which it places the heads or handles as soon as they are produced. From these trays, the pieces are taken by an assembler machine, which puts together one head and one handle to produce a hammer, which is placed in a different tray. From this tray, the polisher takes hammers, works on them and leaves them in a different tray.
Pre- and post-conditions. The behavior of the system can be expressed in UML and OCL by different means. One of the most common ways is by adding the specification of pre- and post-conditions to the operations, defining their behavior. This is shown below for get() and put() operations of class Tray.
put ( p : Part ) pre notFull : self . parts >size ( )<cap p o s t ElementAdded : self . parts=self . parts@pre >append ( p ) get ( ) : Part pre notEmpty : self . parts >size ( )>0 p o s t FirstElementRemoved :
Class diagram HeadGenerator counter : Integer start() generate() : Head
PartGenerator
Assembler
Polisher start() HandleGenerator counter : Integer start() generate() : Handle
start() assemble(hd : Head, hl : Handle) : Hammer polish(hm : Hammer)
Machine
PlantElement processingTime : Integer * output MachineConsumption start() 1..* input
MachineProduction
Behavior of operations. USE also permits to
specify the behavior of operations using a simple
executable language called SOIL [
single ( ) . get ( ) ; hl:=self . input >select ( t j t . parts >size>0 and t . parts >forAll ( oclIsTypeOf ( Handle ) ) ) >
single ( ) . get ( ) ; hm:=self . assemble ( hd . oclAsType ( Head ) ,
hl . oclAsType ( Handle ) ) ; self . output . put ( hm ) ; end end psm PutGet states init : initial Empty [ self . parts >size ( ) =0] Normal [0<self . parts >size ( ) and
self . parts >size ( )<self . cap ]
Full [ self . parts >size ( ) =self . cap ] transitions init > Empty f create g Empty > Normal f [ self . cap>1] put ( ) g Normal > Normal f [ self . parts >size ( )<cap 1] put ( ) g Normal > Full f [ self . cap>1 and
self . parts >size ( ) =cap 1] put ( ) g Empty > Full f [ self . cap=1] put ( ) g Full > Empty f [ self . cap=1] get ( ) g Full > Normal f [ self . cap>1] get ( ) g Normal > Normal f [ self . cap>1 and
self . parts >size ( ) >1] get ( ) g
Normal > Empty f [ self . parts >size ( ) =1] get ( ) g State machines. UML permits specifying the behavior of indi- assemble ( hd : Head , hl : Handle ) : Hammer vidual objects by means of State machines that determine how begin destroy hd , hl ; their internal state changes as a result of the invocation of their result:=new Hammer ; result . isPolished:=false ; provided operations. USE/OCL permits formally specifying end state machines for individual objects, and then automatically Executing the specifications. Once we have the behavior of deriving the corresponding UML diagram. For example, the the operations, we can execute the system by providing a following listing shows the specification of the state machine sequence of SOIL commands that create the initial objects of a Tray. The corresponding UML diagram is shown in of the system, their links, and invokes the operations. Based Figure 2. on the specifications above, for example, we can show the students how to simulate the system, by creating an initial model of the system and invoking the start() operation to the four machines. -- Machines ! new HandleGenerator ( ’hag’ ) ! new HeadGenerator ( ’heg’ ) ! new Assembler ( ’asm’ ) ! new Polisher ( ’pol’ ) -- Trays ! new Tray ( ’Handle2Assem’ ) ! Handle2Assem . cap : = 4 ; ! new Tray ( ’Head2Assem’ ) ! Head2Assem . cap : = 4 ; ! new Tray ( ’Assem2Polish’ ) ! Assem2Polish . cap : = 4 ; ! new Tray ( ’Polish2Out’ ) ! Polish2Out . cap : = 4 ; -- Production Line Connections
Figure 3 pictorially shows a filmstrip of the behavior of the system as a sequence of snapshots after every operation execution. Aggregation associations are used to visualize ‘ownership’ between objects (e.g. a part is placed on a tray).
We have also developed a video with the complete filmstrip1.
Object interactions. So far we have focused on the structural view of the system and the behaviour of individual objects.
UML also permits representing the interactions between objects by means of Sequence and Communication diagrams.
With USE/OCL, we are able to automatically derive them from 1http://atenea.lcc.uma.es/Descargas/EduSymp17/3Hammers.mp4?dl=0 the simulation of the system’s behavior described above, in terms of sequences of operations invocations. First, the interactions are recreated using the UML sequence diagram shown in Fig. 4, that is automatically constructed by USE/OCL.
The behavior can also be displayed as a communication diagram as in Fig. 5. Interestingly, for every step we can represent the current states of all the state machines of the Tray objects—not shown here for space reasons, although they are similar to the one depicted in Fig. 2 but with the current state highlighted; the interested reader can see the presentation2 we have developed to show the state changes. Also, all the code developed for this case study is available3.
Once we have the specifications, there are different kinds of analyses that we can perform on the system that show some of the potential advantages of developing model-driven system descriptions with UML and OCL. In particular: visualization 2http://atenea.lcc.uma.es/Descargas/EduSymp17/snapshots-buffer.pdf?dl=0 3http://atenea.lcc.uma.es/Descargas/EduSymp17/sources.zip?dl=0 of complex structures and processes; execution and simulation of scenarios (operation call sequences); checking structural properties of the system within states by OCL queries (e.g. calculating the number of finally produced parts); checking behavioral properties (e.g., testing the executability of an operation by testing its pre-conditions); checking for weakening or strengthening model properties (invariants, contracts, guards) by executing a scenario with modified constraints; proving general properties within the finite search space with the USE model validator, such as structural consistency (i.e. all classes are instantiable); behavioral consistency (i.e. all operations can be executed); deadlocks (e.g. construction of deadlock scenarios due to inadequate buffer capacities), etc.
The relationships between the views can also be explored with this approach. One of the most interesting examples happens when one of the views is changed, and the effects of this change on the rest of the views. For example, when an invariant is added or a class is changed or removed; when an element changes its name; or when a guard for a state change is altered. Every kind of change in a model has a different impact on the validity of another model, and therefore it requires the other model view to be updated. Students can learn from the effects of each change, and understand how views are related.
Finally, we want to highlight the importance of running
structural tests on the metamodels. One of them concerns
their instantiability and their ability to faithfully represent
the application domain. For example, we decided to ask the
USE model validator [
III. LESSONS LEARNED
Our experience of teaching UML views with USE/OCL has been very positive. At the beginning the students feel uneasy with OCL because they are used to build UML models that are always right (As Bertran Meyer used to say: “Bubbles never crash”). But they progressively discover the advantages of being able to check that the models they are building are correct. Furthermore, they discover the relations between the different views of a system, and how changes in the model manifest in the views.
Another interesting benefit of our approach is that we can follow an incremental development process for building the models. Starting from a simple class diagram we can incrementally add classes, associations, attributes, operations, invariants, contracts, soil operation implementations and protocol state machines. Another feature that students like very much is creating object models. They then discover that models are more than pictures, but assertions on the objects that conform a system (and their relationships). This incremental development process supports direct feedback and model improvements. They discover that modelling is similar to programming, in the sense that you write a program and execute it to check whether its behavior is as you expected. Students can check their models using various functionalities available in USE: the diagrams, the evaluation browser, the class extent, the single object window, the class invariants window, etc. And they also learn that views are not completely independent. On the contrary, they are all projections of an underlying model.
IV. CONCLUSIONS
In this paper we have presented a case study modeled with UML and OCL/USE that has been successfully used to teach modeling in class. It does not only focus on the different views of the system but also on the relationships the different models have among them. Furthermore, we disclose several of the advantages of modeling with UML/OCL and USE.
ACKNOWLEDGMENT
This work is partially funded by the Spanish Research Project TIN2014-52034-R. We would like to thank the anonymous reviewers for their valuable comments and suggestions.