This short paper first presents a modeling language for collaborative learnflows. This language is based on ideas from the area of business process modeling. Second, it is shown how to automatically generate respective learnflow models from log files of learning systems. Recent Advances in Petri Nets and Concurrency, S. Donatelli, J. Kleijn, R.J. Machado, J.M. Fernandes (eds.), CEUR Workshop Proceedings, ISSN 1613-0073, Jan/2012, pp. 151{159.
Business processes have been established in the research and application field of
business process resp. workflow engineering with matured methods, representations and
computer support with tools. In contrast, the closely related learning and teaching
processes only recently gained attention in research and practice and have not yet
created shared terms, methods, and representations. This is especially true for the field
of Computer-supported Collaborative Learning (CSCL), a discipline that investigates
in the affordances and effects of computer applications supporting groups of students
in knowledge construction and skill development. Thus, while we will call the formal
representation of learning / teaching processes learnflow engineering in this paper, this
term is neither firmly established nor fully deserves the engineering character, but is
approaching this currently with the work of our colleagues and our own contributions.
To reach this goal we compared in earlier work [
Of particular interest are the explicit representation of collaborative learning and
of roles and learning groups. In comparison to business processes [
In this paper we will present a modeling language for learning processes that takes
specifically into account the requirements identified above. To make use of expertise
and experience from workflow engineering we will build the proposal upon sound
existing approaches from this field [
A first modeling approach in this direction has been proposed in [
Because of the significance of role changes in the modeling of learning processes in this paper we propose a refinement of that approach. We explicitly model dynamic role assignments and changes in a state diagram: actors can change their assigned roles when performing activities, which means that the role changes in the state diagram are synchronized with the activities in the process model (Petri net). Learning groups are taking into account by collaborative activities performed by several roles jointly.
We will discuss the potential and methods for the automated synthesis of these
models from real protocol instances as an approach for collaboration flow mining. For this
we extend our first proposal of a learnflow mining approach presented in [
In Section 2 we will present our new modeling language by an example learning process. By means of this example we also illustrate the core ideas of collaboration flow mining in Section 3. 2
As an example we consider the following computer supported learning scenario. Groups of three students use the tool Freestyler (www.collide.info) to learn the effect of different factors such as lightning conditions and CO2-concentration on the growth of plants. For this purpose, Freestyler provides several tabs with different functionalities. There are for instance tabs to formulate questions, to create simple models or to import data from a simulation tool. In this example, the set of tabs corresponds to the set of supported learning activities. Namely we consider the following activities: In = Introduction, Qu = Elaboration of the Research Question, Pl = Planning, Mo = Modeling of the Relations of the Different Factors, Hy = Hypothesize, E1 & E2 = Experiment One resp. Two for Hypothesis Testing, Da = Study of Existing Experimental Data for Hypothesis Testing, An = Analysis of Experimental Results Including Comprehensive Hypothesis Testing, Pr = Presentation of the Research Results. Some of these learning activities require collaboration (In, Hy, An require all three learners and Pl, Mo, Pr each require two learners).
In this context a learnflow model first describes the order in which the tabs have to be processed by the learners. Second, it determines who is allowed to work on a tab. This depends on the dynamic roles of the learners within the learning group. The learners may have the role Student, Modeler, ExModeler, Recorder and ExRecorder. Student is the default role. The other roles encode the learning history of the learners, e.g. Recorder and ExRecorder store the information that the learner has performed the activity Question.
Figure 1 together with Figure 2 show a possible learnflow model for the example scenario. Figure 1 illustrates the process aspect in the form of a Petri net with transition annotations. The annotations refer to the numbers of roles required for an activity. The state chart of Figure 2 complements the Petri net model. It represents a consistent role diagram, which models the dynamic roles of the three learners in the pool of actors. Each learner corresponds to one instance of the state chart. Instead of state charts, it would also be possible to consider state machine Petri nets to model the roles of learners, but state charts are in our opinion the more natural modelling approach.
The dynamic of the learnflow model is as follows. An activity of the net can only be accomplished, if the pool of actors contains learners having the roles annotated at the transition. For instance, the collaborative activity Pl requires two actors with the role Student. The occurrence of a transition can change the roles of the involved actors. Such change is modeled in the role diagram by a state transition with the activity name as the input symbol. Therefore, in our example the activity Pl causes the two students to switch over to the role Modeler. This role is later on required to perform the activity Mo. For simplicity of the role diagrams, we use the following convention. If an actor performs an activity, which does not explicitly cause a change of his role in the state chart, he preserves his role. For instance, the activity Mo does not change the role of an actor with the role Modeler and therefore can be neglected in the state chart. 3 Students
In 2 Students
Pl Qu Student
2 Modelers AND Recorder
Mo 2 Modelers
Hy
Modeler OR Recorder
E1
E2 Modeler OR Recorder
Da Modeler OR Recorder 2 ExModelers AND ExRecorder
An
Pr
ExModeler AND ExRecorder
The example shows, that the presented modeling
language allows to comprehensibly represent
collaborative activities as well as dynamic roles and the
learnPl Modeler E1,E2,Da ExModeler ing progress of learners within a learning process. Still
the language is simple and intuitive. It naturally extends
Student well established modeling approaches from the domain
Qu Recorder E1,E2,Da ExRecorder of business process management. The approach
supports a clear separation of the process perspective and
Fig. 2. State chart represent- the role perspective of a learn flow.
ing a role diagram For a formal definition of the occurrence rule of the
new modeling language, we consider a translation of
respective learn flow models into a special class of
colored Petri nets [
Figure 3 illustrates the described translation for our example model (for the sake of clearness, the single ressource pool place is splitted in the illustration). The resulting high-level model on the one hand does not any more show explicitely the dynamic roles and the behavior of the learners. On the other hand it is quite difficult to read and understand. Therefore, for modeling purposes, the original representation should be prefered. The high-level view should only be used for formal considerations. 2`“ExModeler“++ 1`“ExRecorder“ 1`“ExModeler“++ 1`“ExRecorder“ 1`“ExModeler“++ 1`“ExRecorder“
Pr In
There is the following important observation for our new modeling approach. The learning progress and the learning history of the actors are encoded in the role diagram. For instance, the activity E1 initiates a learning progress of the involved learner. This is represented by a change of the role of the learner. The new role then does not allow an execution of E2 and Da by this learner anymore. Thus, the three activities E1, E2 and Da have to be divided among the three learners. As an outlook, we also work on a
Hy
E1 [(x=“Modeler“ andalso y=“ExModeler“) orelse (x=“Recorder“andalso y=“ExRecorder“)]
E2 An [(x=“Modeler“ andalso y=“ExModeler“) orelse (x=“Recorder“andalso y=“ExRecorder“)]
Da [(x=“Modeler“ andalso y=“ExModeler“) orelse (x=“Recorder“andalso y=“ExRecorder“)] 2`“Modeler“++ 1`“Recorder“ x 2`“ExModeler“++ 1`“ExRecorder“
further similar modeling language which avoids such progress-dependend role changes by applying a nets-in-nets concept.
Lastly, our modeling approach regards learning groups implicitly by means of collaborative activities. In view of an explicit modeling of groups, there are two natural and useful possibilities. First of all, different groups can simply be represented by different process instances. However, in this case an extension of the modeling language which allows to model dependencies of process instances would be helpful to regard dynamic group structures. Second, groups can also be modeled analogously as roles, i.e. the role diagrams of the actors can also capture information about group membership of actors. However, in contrast to roles it is important to represent the overall dynamic of the groups. This dynamic can only implicitly be regarded by group-memberships of single actors. Therefore, an extension of the modeling approach which at any time explicitly represents the learning groups would be interesting. This can for instance be achieved by a respective grouping of the state charts in the pool of actors. 3
In this section we introduce an approach to mine a learnflow model given a log file containing recorded learning activities. We construct a learnflow model which reflects a learning process performed by the students (maybe unknown to the teacher) or if the log file is filtered by the teacher even a desired learning process.
If an information system supports an actor while performing a learning activity this event can be recorded and gathered in protocol instances. Each recorded event contains information about the respective process instance, the name of the activity, the time of its occurrence and the involved actors. First, the events are ordered by their respective process and process instance. Second, they are ordered by the time of their occurrence within each process instance. Thus, each process instance yields a sequence of activities together with the respective actors. In the following we use these sequences as an input to a mining algorithm creating a process model. This process model can be used for verification and analysis issues or even as an input for information systems controlling the learnflow.
The tool Freestyler records the activities of the students. Figure 4 shows a part of a Freestyler log file of the considered learning process. It also shows a sequence of activities together with the corresponding actors resulting from that log file. The teacher may filter the log file by adding additional learning sequences or by removing unwanted learning sequences according to certain criteria such as subsequently measured learning achievements. In this case the mining yields a model of the desired learning process, while without filtering a model of the actual behaviour of the students is generated.
In the following we assume the log file to be complete for the given learning process,
i.e. each possible learning sequence of the learning process is recorded in the log, where
we distinguish learning sequences in the form shown in the last table of Figure 4. After
abstracting from the set of actors in the learning sequences well know process mining
algorithms [
Process Process instance Action Student Time Photosynthesis Group A Introduction Andi, Basti, Robin 10:03:12 Photosynthesis Group A Question Robin 10:06:43 Photosynthesis Group B Introduction Bert, Caro, Hans 10:07:33
... ... ... ... ...
Group A (Introduction; Andi,Basti,Robin), (Question; Robin), (Planning; Andi,Basti), (Modeling; Andi,Basti), (Hypothesis; Andi,Basti,Robin), (Experiment1; Andi), (Experiment2; Robin), (Data; Basti), (Analysis; Andi,Basti,Robin), (Presentation; Andi,Robin) ...
Introduction, Planning, Modeling, Hypothesis, Experiment1, Analysis, Presentation Introduction, Planning, Modeling, Hypothesis, Data, Analysis Introduction, Question, Hypothesis, Experiment2, Analysis, Presentation ...
Group A (Introduction; -,-,-), (Question; In), (Planning; In,In), (Modeling; InPl,InPl),
(Hypothesis; InPlMo,InPlMo,InQu), (Experiment1; InPlMoHy), (Experiment2; InQuHy), (Data; InPlMoHy),
(Analysis; InPlMoHyE1,InPlMoHyDa,InQuHyE2), (Presentation; InPlMoHyE1An,InQuHyE2An)
...
of a log file if this is possible. Precise mining algorithms for Petri nets are base on
the so called theory of regions. In [
For every learning sequence and each occurring student within the learning sequence we consider the sequence of activities the student performs. Figure 4 shows this projection of the learning sequences onto the students for the considered example. All these sequences are integrated into a deterministic state chart in the form of a tree. Its states are determined by the history of previously performed activities (also regarding the order of the activities) and are named accordingly. In our example the resulting state chart is given in Figure 5 yielding a first model of roles for our learning process. In order to consistently use these roles as annotations in the Petri net model, in every learning sequence each actor must be renamed by the role describing the activities performed by the actor in the history of this learning sequence (see Figure 4 lower part). The role annotation of an activity in the Petri net is determined by all roles or combinations of roles in the case of a collaborative activity that occur together with this activity in any such learning sequence.
Although we have not formally proven this yet, it can be shown that using this approach and given a complete log file, i.e. a complete set of learning sequences, a model is calculated which has the same behaviour as show in the log file (if such a model exists). That means, the mined model and the log define the same learning sequences in the form depicted in the last table of Figure 4. In our example the generated model has equivalent behaviour to the learning process model shown in Figure 1. Yet the model has a much lager set of roles. The reason for this is that the role model encodes the complete history of each actor.
E1 E2 Da E1 Da
InPlHyE1 InPlHyE2
Da
An An An An An An
Pr Pr Pr Pr Pr
Pr InPlHyE1An
InPlHyE1AnPr InPlHy
InPlHyE2An
InPlHyE2AnPr InPlHyDa
InPlHyDaAn
InPlHyDaAnPr InQuHy
E2 InQuHyE2
InQuHyE2An
InQuHyE2AnPr InQuHyE1
InQuHyE1An
InQuHyE1AnPr InQuHyDa
InQuHyDaAn
InQuHyDaAnPr An An An
Pr Pr
Pr E1 InPlMoHyE1
InPlMoHyE1An
InPlMoHyE1AnPr InPlMoHyE2
InPlMoHyE2An
InPlMoHyE2AnPr InPlMoHyDa
InPlMoHyDaAn
InPlMoHyDaAnPr Pl Qu
InPl
Mo InQu
Hy
Hy - In
In
Hy InPlMo
InPlMoHy
E2
In the following our goal is to simplify the model of roles by combining roles. Therefore, we developed the following rules. Remark that the annotations in the Petri net model have to be renamed consistently.
– Role transitions triggered by actions performed collaboratively by all actors belonging to one process instance can be neglected. – Roles having the same postset of roles (respectively an empty postset) and the same outgoing activities can be fused, if for each outgoing activity the roles occur together with the same roles over all learning sequences. Thereby, outgoing activities between the roles to be fused can be neglected. – Only as a last step roles having an empty postset can be neglected.
It can be proven, that given a complete log file, applying these rules to the previously mined role diagram again yields a behaviour equivalent learnflow model. In our example with these three rules we get a model of roles which is isomorphic to the model shown in Figure 2. Apart from the role names that are not present in the log files anyway we were in this case able to recreate the original learning process model from a complete log file. The role names have to be assigned by the teacher afterwards.
Finally, in practical settings typically we have to assume that not all possible
learning sequences have been recorded in a log file. For such log files the presented approach
has to be adapted. Heuristics can help to infer the missing sequences and to integrate
them into the process model. For the control flow perspective existing methods from the
area of process mining can be used in this context [