October 2006 Volume 9 Number 4

Pawlowski (2002) is a first approach for identifying and taking into account the specific enterprise aspects of a
TEL development. But it is restricted and only synthesizes the different projects in educational systems quality
insurance. Moreover, this work does not contribute to defining a unique framework including other approaches
such as, for instance, the existing standard proposals. Oubahssi et al. (2004) want to define a new meta descriptor
which allows the designers to describe each type of learning object (which here could be a web document, a
video,… but also a scenario, a service, a role, …) during all phases of the design, the use and the analysis of a
TEL system. But the enterprise viewpoint is not supported here: only the computational and information
viewpoints are taken into account.
The proposal of an enterprise viewpoint for the reengineering of TEL systems we make here, as shown in Figure
2, aims to integrate both the different constraints existing in a reengineering process and the specificities of the
use of TEL standards. We use the vocabulary described in (ISO/IEC-15414, 2002):
Process: a collection of steps taking place in a prescribed manner and leading to an objective. A Process is a
set of tasks which operate and produce information for reaching and operational objective.
Community: a collection of enterprise objects which share the same objectives. A Community is constituted
by humans, informative resources and/or tools which share the same objective into the system under
specification.
Enterprise Object: a basic entity of the enterprise specification to fulfill one or more roles. An Enterprise
Object could be any component of the system specification which could assume at least one basic function
in the operational system.
Role: abstraction of an enterprise object behavior or a community behavior. A Role emphasizes the
comportment of one entity or a set of them.
Actor: an enterprise object that participates in the action. Thus, the term Actor qualifies the entities which
participate to a named interaction with other objects.
Action: Action is a basic modeling concept to qualify each object within an ODP system. An Action allows
the definition of an interaction inside an object or between several objects.
Objective: a practical advantage or intended effect, expressed as preferences about future states.
Behavior: A behavior of an object is a collection of actions that the object may take part in, together with
the set of constraints on when those actions can occur.
Artifact: an enterprise object that is referenced in the action, that is to say, that is necessary for performing
the action.
Resource: an enterprise object which is essential to some behavior.
Step: An abstraction of an action, used in a process that may leave unspecified objects that participate in that
action. This term allows the definition of actions prototypes.
Graphical conventions are taken from the ECA (Enterprise Collaboration Architecture) UML profile, as
proposed by the OMG consortium (OMG/ECA, 2004). This profile aims to support a model driven development
process, in an RM-ODP framework (Nagase et al., 2004).
The enterprise viewpoint we propose for the TEL systems reengineering is composed of six processes, described
here with the help of the vocabulary and rules proposed by RM-ODP.
The Design Process produces specifications guided by the main standardized informational models of TEL (e.g.
LOM and Learning Design). These specifications need to be adapted to existing resources (learning objects) and
learner profiles, and/or modified, taking into account information produced by the Analysis Process (uses
analysis, system comportment).
The Software Engineering Process interprets the designers' specification and produces a prototype of the TEL
system (we consider here each system as a prototype which could be modified by reengineering). This process
has to negotiate with the Design Process and the Analysis Process in order to define the observation needs of a
learning session and to develop and integrate the related software captors.
The Learning Process supports the learning sessions. It reifies the scenario specified by the Design Process and
implemented by the Software Engineering Process in the prototype. This scenario leads to the organization of
some actions, named activities in Learning Design, performed by the actors' roles of the learning session.
The Analysis Process operates computational and manual use analysis techniques. Its negotiation with the
Software Engineering Process could establish new needs: events to observe and/or new interpretations. Uses
analysis feedback is provided to the Design Process.
231