=Paper=
{{Paper
|id=Vol-2019/edusymp_4
|storemode=property
|title=Teaching Model Views with UML and OCL
|pdfUrl=https://ceur-ws.org/Vol-2019/edusymp_4.pdf
|volume=Vol-2019
|authors=Loli Burgueño,Antonio Vallecillo,Martin Gogolla
|dblpUrl=https://dblp.org/rec/conf/models/BurguenoVG17
}}
==Teaching Model Views with UML and OCL==
https://ceur-ws.org/Vol-2019/edusymp_4.pdf
Teaching Model Views with UML and OCL
Loli Burgueño Antonio Vallecillo Martin Gogolla
Universidad de Málaga, Spain Universidad de Málaga, Spain University of Bremen, Germany
loli@lcc.uma.es av@lcc.uma.es gogolla@informatik.uni-bremen.de
Marbella International University Centre, Spain
lola@miuc.org
Abstract—The specification of any non-trivial system is nor- The rest of the paper is structured as follows. The next
mally composed of a set of models. Each model describes a Sect. II describes the example and shows interesting properties
different view of the system, focuses on a particular set of using the USE modeling environment [1], [3]. Section III
concerns, and uses its own notation. For example, UML defines
a set of diagrams for modelling the structure and behavior of presents the lessons we learned. Finally, Section IV presents
any software system. One of the problems we perceived with our our conclusions and future work.
students is that they are able to understand each one of these
diagrams, but they have problems understanding how they are II. A UML AND OCL M ODEL FOR A P RODUCTION L INE
related, and how the overall system specifications work when S YSTEM
composed of a set of views. This paper presents a simple case Let us illustrate our approach by modeling a plant that
study that we have developed and successfully used in class, which
permits students developing the principal views of a system, produces hammers. This plant is composed of four machines:
simulate them, and check their relations. one that generates hammer heads, another that generates
handles, one that assembles heads and handles, and finally
I. I NTRODUCTION one that polishes the hammers. There are also trays that are
Non-trivial systems specifications need to be decomposed used to collect the goods in production.
in various models (views), each one focusing on a particular The plant operates as follows: each generating machine has
set of concerns and described in a particular notation. For an associated tray, in which it places the heads or handles
example, UML defines a set of diagrams for modelling a as soon as they are produced. From these trays, the pieces
system that permit describing its structure (class diagrams), are taken by an assembler machine, which puts together one
the behavior of its individual objects (state machines), the head and one handle to produce a hammer, which is placed
collective behavior of collections of objects (communication in a different tray. From this tray, the polisher takes hammers,
and sequence diagrams), etc. There are two main problems that works on them and leaves them in a different tray.
we have perceived with our students when teaching the use of
A. Structural Elements
models. First, they normally tend to see models as drawings,
mostly used for communication among humans, and not as Figure 1 shows in a UML class diagram the structural
software artefacts that need to be processed by computers. elements of the system. We can see how each Tray has
Hence they tend to be less precise and formal than when a capacity (cap) and each Machine keeps record of the
developing programs. And second, when dealing with multi- time that its job takes (processingTime). Futhermore,
viewpoint models, students may be able to understand each the head and handle generators (HeadGenerator and
one of these diagrams, but they have problems understanding HandleGenerator) keep a counter of the number of el-
how they are related, and how the overall system specifications ements that have produced (counter). In order to perform
actually work when composed of a set of views. the actions of placing or removing pieces from the trays, class
This paper presents a simple case study that we have devel- Tray provides get() and put() operations.
oped and successfully used in class, which permits students B. Behavioral Elements
to develop the principal views of a system, simulate them,
Pre- and post-conditions. The behavior of the system can be
and understand their relationships. We use a combination
expressed in UML and OCL by different means. One of the
of UML and OCL and the possibilities that the OCL/USE
most common ways is by adding the specification of pre- and
tool [1] provides to simulate and analyse the models, as proper
post-conditions to the operations, defining their behavior. This
software artefacts.
is shown below for get() and put() operations of class
The example we present here—originally defined in [2]—
Tray.
is based on a production line and it is modeled using a
put ( p : Part )
combination of UML and OCL. We show how these notations pre notFull : self . parts−>size ( )append ( p )
get ( ) : Part
views, and allow performing several interesting analyses on the pre notEmpty : self . parts−>size ( )>0
system. p o s t FirstElementRemoved :
Class diagram
Machine PlantElement Tray
processingTime : Integer * output cap : Integer
MachineConsumption
start() * input put(p : Part)
MachineProduction
get() : Part
1..* input
size() : Integer
1 output
1 tray
PartGenerator Assembler Polisher Contains * parts {ordered}
start() start() Part
assemble(hd : Head, hl : Handle) : Hammer polish(hm : Hammer)
HeadGenerator HandleGenerator Head Handle Hammer
counter : Integer counter : Integer isPolished : Boolean
start() start()
generate() : Head generate() : Handle
Fig. 1. Class diagram for the production line example.
result=self . parts@pre−>at ( 1 ) and Behavior of operations. USE also permits to
self . parts@pre=self . parts−>prepend ( result )
specify the behavior of operations using a simple
executable language called SOIL [4]. For instance,
the behavior of Assembler::start() and
Assembler::assemble() operations can be specified as
follows.
start ( )
begin
declare hd : Part , hl : Part , hm : Hammer ;
hd : = self . input−>select ( t | t . parts−>size>0 and
t . parts−>forAll ( oclIsTypeOf ( Head ) ) )−>
single ( ) . get ( ) ;
hl : = self . input−>select ( t | 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 ) ;
Fig. 2. State Machine for Tray objects. end
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
psm PutGet students how to simulate the system, by creating an initial
states
init : initial model of the system and invoking the start() operation to
Empty [ self . parts−>size ( ) = 0 ] the four machines.
Normal [0size ( ) and
self . parts−>size ( )size ( ) =self . cap ] ! new HandleGenerator ( ’hag’ )
transitions ! new HeadGenerator ( ’heg’ )
init −> Empty { create } ! new Assembler ( ’asm’ )
Empty −> Normal { [ self . cap>1] put ( ) } ! new Polisher ( ’pol’ )
Normal −> Normal { [ self . parts−>size ( ) Full { [ self . cap>1 and ! new Tray ( ’Handle2Assem’ )
self . parts−>size ( ) =cap−1] put ( ) } ! Handle2Assem . cap : = 4 ;
Empty −> Full { [ self . cap = 1 ] put ( ) } ! new Tray ( ’Head2Assem’ )
Full −> Empty { [ self . cap = 1 ] get ( ) } ! Head2Assem . cap : = 4 ;
Full −> Normal { [ self . cap>1] get ( ) } ! new Tray ( ’Assem2Polish’ )
Normal −> Normal { [ self . cap>1 and ! Assem2Polish . cap : = 4 ;
self . parts−>size ( ) >1] get ( ) } ! new Tray ( ’Polish2Out’ )
Normal −> Empty { [ self . parts−>size ( ) = 1 ] get ( ) } ! Polish2Out . cap : = 4 ;
end -- Production Line Connections
Fig. 3. Object diagram sequence displaying the behavior of the system.
! insert ( hag , Handle2Assem ) into MachineProduction the simulation of the system’s behavior described above, in
! insert ( heg , Head2Assem ) into MachineProduction
! insert ( Handle2Assem , asm ) into MachineConsumption
terms of sequences of operations invocations. First, the inter-
! insert ( Head2Assem , asm ) into MachineConsumption actions are recreated using the UML sequence diagram shown
! insert ( asm , Assem2Polish ) into MachineProduction
! insert ( Assem2Polish , pol ) into MachineConsumption
in Fig. 4, that is automatically constructed by USE/OCL.
! insert ( pol , Polish2Out ) into MachineProduction The behavior can also be displayed as a communication
-- Process
! heg . start ( )
diagram as in Fig. 5. Interestingly, for every step we can
! hag . start ( ) represent the current states of all the state machines of the Tray
! asm . start ( )
! pol . start ( )
objects—not shown here for space reasons, although they are
similar to the one depicted in Fig. 2 but with the current state
Figure 3 pictorially shows a filmstrip of the behavior of highlighted; the interested reader can see the presentation2 we
the system as a sequence of snapshots after every opera- have developed to show the state changes. Also, all the code
tion execution. Aggregation associations are used to visualize developed for this case study is available3 .
‘ownership’ between objects (e.g. a part is placed on a tray).
We have also developed a video with the complete filmstrip1 . C. Further analysis
Object interactions. So far we have focused on the structural Once we have the specifications, there are different kinds of
view of the system and the behaviour of individual objects. analyses that we can perform on the system that show some
UML also permits representing the interactions between ob- of the potential advantages of developing model-driven system
jects by means of Sequence and Communication diagrams. descriptions with UML and OCL. In particular: visualization
With USE/OCL, we are able to automatically derive them from
2 http://atenea.lcc.uma.es/Descargas/EduSymp17/snapshots-buffer.pdf?dl=0
1 http://atenea.lcc.uma.es/Descargas/EduSymp17/3Hammers.mp4?dl=0 3 http://atenea.lcc.uma.es/Descargas/EduSymp17/sources.zip?dl=0
Fig. 4. Sequence diagram.
of complex structures and processes; execution and simulation on the validity of another model, and therefore it requires the
of scenarios (operation call sequences); checking structural other model view to be updated. Students can learn from the
properties of the system within states by OCL queries (e.g. effects of each change, and understand how views are related.
calculating the number of finally produced parts); checking Finally, we want to highlight the importance of running
behavioral properties (e.g., testing the executability of an oper- structural tests on the metamodels. One of them concerns
ation by testing its pre-conditions); checking for weakening or their instantiability and their ability to faithfully represent
strengthening model properties (invariants, contracts, guards) the application domain. For example, we decided to ask the
by executing a scenario with modified constraints; proving USE model validator [3] to generate a plant configuration
general properties within the finite search space with the USE using the system metamodel. The resulting object diagram is
model validator, such as structural consistency (i.e. all classes shown in Fig. 6. Interestingly, the produced system is wrong.
are instantiable); behavioral consistency (i.e. all operations The polisher is not connected to any tray that provides it
can be executed); deadlocks (e.g. construction of deadlock with hammers. This motivates the need to develop additional,
scenarios due to inadequate buffer capacities), etc. currently missing invariants (on the structural system level)
The relationships between the views can also be explored and demonstrates the potential usefulness of this approach
with this approach. One of the most interesting examples for validating these kinds of properties which are normally
happens when one of the views is changed, and the effects overlooked for being considered obvious.
of this change on the rest of the views. For example, when an
III. L ESSONS L EARNED
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 Our experience of teaching UML views with USE/OCL has
altered. Every kind of change in a model has a different impact been very positive. At the beginning the students feel uneasy
Fig. 5. Communication diagram.
Fig. 6. Generated test case for Producer-Consumer-Tray configuration.
with OCL because they are used to build UML models that like very much is creating object models. They then discover
are always right (As Bertran Meyer used to say: “Bubbles that models are more than pictures, but assertions on the
never crash”). But they progressively discover the advantages objects that conform a system (and their relationships). This
of being able to check that the models they are building are incremental development process supports direct feedback and
correct. Furthermore, they discover the relations between the model improvements. They discover that modelling is similar
different views of a system, and how changes in the model to programming, in the sense that you write a program and
manifest in the views. execute it to check whether its behavior is as you expected.
Students can check their models using various functionalities
Another interesting benefit of our approach is that we available in USE: the diagrams, the evaluation browser, the
can follow an incremental development process for build- class extent, the single object window, the class invariants
ing the models. Starting from a simple class diagram we window, etc. And they also learn that views are not completely
can incrementally add classes, associations, attributes, oper- independent. On the contrary, they are all projections of an
ations, invariants, contracts, soil operation implementations underlying model.
and protocol state machines. Another feature that students
IV. C ONCLUSIONS
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 anony-
mous reviewers for their valuable comments and suggestions.
R EFERENCES
[1] M. Gogolla, F. Büttner, and M. Richters, “USE: A UML-based speci-
fication environment for validating UML and OCL,” Sci. Comp. Prog.,
vol. 69, pp. 27–34, 2007.
[2] J. E. Rivera, E. Guerra, J. de Lara, and A. Vallecillo, “Analyzing rule-
based behavioral semantics of visual modeling languages with maude,”
in Proc. of SLE’08, ser. LNCS, vol. 5452. Springer, 2008, pp. 54–73.
[3] M. Gogolla and F. Hilken, “Model Validation and Verification Options
in a Contemporary UML and OCL Analysis Tool,” in Proc. Model-
lierung (MODELLIERUNG’2016), A. Oberweis and R. Reussner, Eds.
GI, LNI 254, 2016, pp. 203–218.
[4] F. Büttner and M. Gogolla, “On OCL-Based Imperative Languages,”
Science of Computer Programming, vol. 92, pp. 162–178, 2014.