SEKE 2012 Proceedings - Knowledge Systems Institute

model has two types of diagrams: the Class Diagram and
Sequence Diagrams. Each of these is translated in a different
way, since they contain different types of information, even
though some information is shared between them. We will
begin with the class diagram translation.
In the class diagram, it is possible to identify all the
methods the framework makes available to the user. For each
of these methods, a different operator will be made. The
name of the operator will contain the name of the method
being used and, in order to allow methods with the same
name in different classes, the operator name will also contain
the class name. The resulting operator name will then be
“ClassName.MethodName”.
Following the name, the set of preconditions is built. This
set contains all the elements required to use the method. This
set will contain one proposition “object(Object Type)” if the
method is from an object, that is, the method requires an object
to be used, as opposed to constructors and static methods
that can be used without creating objects first. Next, one
proposition “object(Argument Type)” is added to the set for
each input argument the method has, in which the Argument
Type will be replaced by the corresponding object type. To
conclude this set, a proposition “interface(Used Interface)” is
added if the method requires any interface to be called before
it can be used, and these interfaces are identified by the “use”
dependency relationship.
It is worth noting that, if a method does not have one of
these elements, the respective rule can just be ignored. It may
happen that, in some cases, such as some constructors, the
Precondition set will be empty.
To complete the operator, the Effects set must be built. This
set will contain all the propositions that will become true once
the operator is used. This set will contain one proposition
“object(Return Type)” should the method return any object.
A proposition “interface(Name)” is added to the set if the
method is responsible for implementing a service. The set will
also contain a proposition “link(Type1, Type2)” if the method
creates a link between objects of Type1 (the object that has
the method being used) and Type2 (the second object). This
link can be “created” either with the input argument, as in
the “set” methods of objects, or if it returns an object already
associated with the target object, “get” methods for example.
Lastly, a proposition “sequence(Name)” is added if the method
starts any of the Sequence Diagrams.
To exemplify this process, let us use the class “JFrame”
from the SWING framework, shown in figure 3.
Fig. 3: JFrame Class from the SWING framework
Starting by the “JFrame” constructor method, we get that
the operator name should be “JFrame.JFrame”, since it is
composed of both class and method names. Since this is a
constructor, that has no input argument and does not require
any other interface, its precondition set will be empty. The
effect set will be composed only of its return type, a “JFrame”
object. This will result in the following operator:
Name : JFrame.JFrame
Precondition (PC) : {}
Effect (E) : object(JFrame)
Next, using the “setVisible” method, we get an operator
named “JFrame.setVisible”. Its precondition set will include
one proposition “object(JFrame)”, since this is an object
method (neither static or constructor). Although this method
does not return an object, it is responsible for the interface
“Create Window”, and a proposition “interface(Create
Window)” is added to the effect set. This will result in the
following operator:
Name : JFrame.setVisible
PC : object(JFrame)
E: interface(Create Window)
As a last example, let us use the “validate” method. As the
method used before, this method has no input argument and is
an object method, so the precondition set will be composed of
the proposition “object(JFrame)”. This method has no return
type and it is not responsible for any interface, but it starts
the “Update Screen” mechanism, shown in figure 2. Hence
the effects will include one proposition “sequence(Update
Screen)”, resulting in the operator:
Name : JFrame.validate
PC : object(JFrame)
E : sequence(Update Screen)
This process is repeated for each method described in the
Class Diagram, with each of them generating one operator.
To complete the set of operators representing the framework,
those created from any Sequence Diagram included in the
model must be included. These diagrams contain information
on functionalities that should be accessed through specialized
classes and overwritten methods.
Each Sequence Diagram will be inspected in order to
identify which of the methods it contains can be overwritten.
It is assumed that those methods that do not invoke any other
methods inside their behavior description can be overwritten
without introducing errors in the behavior of the framework.
Once the method to be overwritten is identified, an operator
named “overwrite:ClassName.MethodName” is created.
The precondition set for this operator will be composed
of one proposition “specialization(Class)”, in which Class
represents the class that has the method to be overwritten. The
set also contains a proposition “link(Type1, Type2)” where
Type1 is the type of object that starts the mechanism and Type2
is the type of object being overwritten, and a proposition “sequence(Mechanism)”,
indicating that the Sequence Diagram
must be used for the method to be called.
The effect set of the operator will include one proposition
“interface(Name)”, if the method is responsible for any interface
and one proposition “object(Argument Type)” for each
input argument the method has. The argument type is included
in the effect set, instead of the precondition set like the other
operators, because when overwriting a method, it is possible
to use the input methods, instead of having to supply them
when calling a method.
Then, for each “overwrite” operator made, one additional
operator is included. This operator will be named “special-
565