SEKE 2012 Proceedings - Knowledge Systems Institute

Fig. 11: Overwritten Method
Fig. 12: Altered application Class Diagram
With the model obtained, it is possible to implement the
desired application using the SWING framework.
This is only a simple model. The framework model could
be refined, adding more classes and services to allow more
complex applications, although, currently, the method only
supports applications with a linear sequence of activities, that
is, loops and branches are not yet supported. But the possibility
of reusing a framework model, specially considering
that different software engineers can use the same model in
multiple projects, presents an opportunity to reduce the costs
of using frameworks.
V. RELATED WORKS
This works is based on the web-service composition area.
This area seeks a way to automatically create new Service
Oriented systems, using as input a set of available webservices,
usually described in BPEL.
In [10] the authors describe a way to use model-checking
based planning to build new systems, using as input a set
of BPEL descriptions of web-services, while [11] uses a
knowledge based approach to a similar problem. Another
approach is found in [12], where the authors show a method
that can create a finite state machine representation of the
desired system, based on the behavior description of the
available services.
There is an advantage when working with web-services,
instead of object-oriented systems, because web-services are
well encapsulated components, that can more easily be chained
together than their object-oriented counterparts. Moreover,
the services provided can be considered black-boxes, that is,
only their input and output have to be considered during
development, making possible to ignore the internal workings
and state of the service during usage, which is not true when
working with frameworks.
Frameworks frequently have strict conditions under which
their functionalities can be used. The method presented herein
not only identifies which components from the framework
must be used, but also creates a sequence of methods that
ensure those components will be in the correct state at the
time of their invocation.
Other works have also addressed the reusability problem.
For instance, in [13], a method to identify which parts of
a system can be reused is designed, but it focus more on
identifying ’which’ components can be used, as opposed
to ’how’ to reuse already available components, as is the
case with frameworks. There is also [14], which addresses
the problem in an algebraic manner. The paper presents an
interesting approach, but since it predates the rise of the UML,
it does not address the use concepts of classes, objects and the
exchange of messages.
VI. CONCLUSION
A model-to-model transformation method is presented that
identifies which components from a desired framework should
be used to meet the application requirements.
This method allows for applications to be described as a
sequence of services executions, identifying how to combine
them to implement the desired solution. The aim of this
method, is to make easier to reuse high level models, both
framework and application models. The same application
model could be used several times, with different framework
models, in the same way as the framework model could be
used with several applications.
This method has limitations in its current implementation.
The model generated by the transformation, albeit correct, is
not complete. It lacks the description of how to initialize the
frameworks, using the example shown; for instance, it does
not include a “main” method, which is required in any JAVA
application to be correctly initiated.
Another restriction concerns the input model. The framework
should be modeled in a very precise manner, in order
not to introduce errors in the logical planner, and a nonstandard
way of using the sequence diagrams to describe the
method that can be overwritten without introducing errors in
the framework behavior. The models, both framework and
application, are also very dependent on the use of fixed names
to describe the interfaces (for the framework) and activities
(for the application). In the current state, the application model
is also constrained in the Activity description, in which it is
not currently possible to use loops or branches.
Finally, the model generated through this transformation
process does not consider some of the best practices of
568