October 2006 Volume 9 Number 4

Step 5: Instantiation of the technology viewpoint. From the computational viewpoint, the software engineering
process needs to identify the different states and behaviors of the objects specified by designers. From a
technology viewpoint, it means that the software engineering process needs to develop and integrate software
captors into these objects, in order to track the behaviors of the technology objects corresponding to the
information objects. In our example, it needs to identify what events (signals) could be exchanged and, for each
of these events, identify the emitter and the receptor. One of the design patterns widely adopted by the software
engineering community for this kind of problem is the MVC paradigm (Model/View/Control) described by
Buschmann et al. (1996). It is implemented in the Java library "swing/JFC". Each object proposed by the
designers and relevant to this paradigm could be a traceable object.
Conclusion. The reverse engineering of a TEL system described by this use case is initiated by the design
process but concerns mainly the software engineering process which, guided by the RM-ODP framework, aims
to define the dynamic schema of the TEL system from its information specification. The result of the reverse
engineering process is the artifact shown by figure 7. From the enterprise viewpoint, this artifact increases the
quality of the specification provided by designers: even if it wasn't specified, by asking to themselves questions
suggested by RM-ODP, the software engineers have enhanced the Learning Object in order to track its use. This
result could be shared with designers, and generate new kinds of instructional scenarios by taking into account
these tracking possibilities.
The Use Case of a Reengineering of a TEL System
With Chikofsky’s definition in mind (see before), one can say that reengineering a system is relevant to a model
driven approach, in an iterative development process. The main reengineering acts on a TEL system are the
modifications made by the designers on the informational model of the educational system, especially by taken
into account the uses observed during a learning session. We will present here a reengineering use case where
the analysis process provides information to the design process which is useful to understand better the real
sequence of learning objects that each learner performed. With these data, both the informational and the
software engineering viewpoints are modified. Figure 8 describes the four steps of the use case, one for each
participating role: software engineering process role, learning process role, analysis process role, design process
role.
: software engineering
process
: produce a
prototype
: learning process
: execute a
prototype
: produce an
observable
: design process
: interpret an
information
Figure 8: UML Collaboration Diagram of the Reengineering Use Case
Step 1: the role of the software engineering process. Each reengineering of a system implies its reverse
engineering. In this use case, by applying the reverse engineering pattern (Demeyer et al., 2002), the software
engineering process has developed and integrated captors to the TEL system. This allows the reverse engineering
by producing information on the effects of the decisions made from the engineering viewpoint. Following the
RM-ODP guidelines, the engineering objects are grouped in clusters to reduce the complexity of their
manipulation. Figure 9 is an excerpt of the FreeStyle Learning deployment script on the learners’ computers.
One could see that, even, from an informational viewpoint, there are several objects with a same type (e.g. 3
exercises, 2 slide shows, 2 MCQ), the engineering objects are only the corresponding components (e.g. 1
exercise component, 1 slide show component, 1 MCQ components).
Step 2: the role of the learning process. From the computational viewpoint, these engineering objects are
SCORM components (SCO) provided to each client computer. They are observed and tracked by the LMS
(Learning Management System) following the SCORM technical specification. The transition/state UML
diagram of figure 10 shows the global interaction between the LMS and each SCO.
: analysis process
: analyze an
observable
: produce an
information
236