Maxime Clusel

Timothy Ziman

Transverse magnetization and transient oscillations in the quantum tunneling of molecular magnets

Keywords: . 75.50.Xx Molecular magnets -75.60.Ej Magnetization curves, hysteresis, Barkhausen and related effects -74.25.Nf Response to electromagnetic fields (nuclear magnetic resonance, surface impedance, etc.)

We calculate the response of a molecular magnet subject to a time-varying magnetic field and coupled to a heat bath. We propose that observations of calculated oscillations transverse to the field direction may be an effective way of demonstrating quantum tunneling and thus probing the details of level repulsion. The effective model of a triangle of Heisenberg spins and weak anisotropies, as has been used to model the molecular magnets {V 15 } and {Cu 3 }, is used to illustrate this.

Introduction

Studies of the quantum behavior of open systems are almost as old as quantum mechanics itself. The related phenomena of relaxation and decoherence have passed from conceptual to pratical questions with the improvements of experimental technique during the last decades. One can now build and manipulate physical objects at the borderline between quantum and classical worlds. In the future, materials structured on such a scale may be of use in applications such as very tiny components of magnetic memory and quantum computers. This would require detailed understanding of switching and dissipation between different quantum states. For such memories we can distinguish "dynamical" aspects, related to writing (or reading) of different states, and "relaxational" aspects, concerning the storage itself. If such memories were to be part of future quantum computers, the phase of the wavefunctions is essential and the loss of phase central to the questions of the feasibility of building such a device. It is therefore crucial to understand and control the coupling of the small magnetic object to its environment.

There is a large literature on the subject of two level systems in contact with an environment [1] but in the magnetic systems we shall consider, there are aspects not present in, for example, "qubits" based on Josephson couplings. In particular there is the complexity of the maga clusel@ill.eu b ziman@ill.eu netic spectrum: as we shall see, it is essential to take into account more than two levels to understand the dynamics. Furthermore the nature of the environment is unclear and new experiments should be designed that may shed light on the issue. This paper will address a multi-level problem, calculating the response of a relatively simple magnetic system to a fast-varying magnetic field, including dissipation to a a simple model environment. In the context of quantum computing this corresponds to the "writing" aspect on a potential quantum memory storage device. This will be illustrated using the example of a triangle of magnetic ions, as a model of low spin molecular magnets such as {V 15 } or {Cu 3 }. We choose the triangular geometry because of recent experiments, to be noted later, and because the spectrum is sufficiently rich that it displays at least some of the features not seen in simple two-level systems.

Experimentally, the development of new magnetic coils allowing for the generation of high magnetic fields varying on very short time scales has lead to experiments that can probe such interesting aspects of statistical mechanics. We shall argue that non-equilibrium measurements with pulsed magnetic fields can be more informative, if properly analysed, than equilibrium measurements for fine details of interactions between the spins. Such experiments usually involve solids, where the molecular units repeat, and are assumed to have sufficiently weak interactions that they may be considered as independent, to a first approximation. They are therefore analysed in terms of a static Hamiltonian for the individual molecule, with an additional time-dependent external field. The dissipation is induced by an environment, which represents contributions from coupling to phonons, dipole interactions with other molecules, hyperfine coupling to nuclear spins.

Molecular magnets and Landau-Zener regime

If the interactions between spins were perfectly isotropic, transitions in magnetization would occur by the crossing of eigenvalues of different spins. In real magnets anisotropies mix the levels and, on some scale, crossings are avoided. The dynamics will therefore depend strongly on the fine structure of the molecular levels of the spins. If the level repulsion is weak, as is the case if the anisotropies are small, it may be possible to enter a régime where the temperature is sufficiently low, and the coupling to the environment sufficiently weak, that we can be in a regime of pure quantum tunneling. It is for this reason that there has been great interest in the Landau-Zener tunelling régime [2].

If we consider only two levels with an avoided crossing, the transitions between the two levels, when varying a control parameter such as the external magnetic field, is described by the Landau-Zener formula [3]:

P = 1 -exp - π∆ 2 h2v , (1)
where the "velocity" v is defined by v = d(E1-E2) dt

, and E 1 and E 2 are the eigenvalues of the two levels considered. P is the asymptotic probability for passing to the upper level given the initial condition of a state in the lower. We note that this formula is only for the asymptotic probability of transfer and is for zero temperature; thus it does not fully determine the dynamics. It does, however, suffice to see when quantum tunneling can be relevant. For the argument of the exponential to be sufficiently small that the probability of staying in the lowest level is other than unity, the "velocity" v must usually be extremely large, unless the gap is very tiny: e.g. for ∆ = 1K, quantum tunneling is relevant for velocities greater than v ≈ 10 11 Ts -1 . Thus to attain this regime either ∆ must be extremely tiny or v very large. Two recent sets of experiments do, however, approach the tunneling regime:

(i) In the case of high spin magnets such as {Mn 12 } [2] or {Fe 8 } [4], the two nearly degenerate states correspond to two states of total magnetization S z = ±10 and tunnelling is via a series of virtual transitions to states of smaller |S z | in the multiplet of total S = 10. The energies of these states are determined primarily by the easy axis anisotropy DS 2 z . [5] Since the splitting is tiny, the tunneling probability can be appreciable for very modest changes in the external magnetic field. The experiments are, of course, carried out at temperatures much greater than the energy splitting.

(ii) In low spin magnets such as {V 15 } [6] or {Cu 3 } [7], the active degrees of freedom can be taken to be essentially coupled spin 1/2 moments, seated on the vertex of equilateral triangles. In {V 15 } these may be thought of as the three spin 1/2 V 4+ ions sandwiched between two planes of six ions. As de Raedt et al have shown [8], the extra Vanadium ions renormalize the effective interactions in the plane, but for the fields of interest the out-of-plane spins can otherwise be considered as being locked in inert singlet states. The gaps are generated by Dzalyoshinsky-Moriya (DM) interactions and are typically 10 -2 K so that the velocity needed for Landau-Zener tunnelling would be 10 7 T.s -1 , within range of recent "single-turn" magnets [9]. The advantage of these compounds compared to those of (i) is that experiments can be conducted at temperatures comparable to the splittings, thus a different régime of non-equilibrium phenomena can be studied. Furthermore Choi et al. have suggested that the extra degeneracy of different chiral states of the triangular structures may be useful for applications [7].

A problem in the interpretation of past experiments is that it is not necessarily clear whether one is really in the tunneling regime. One approach has to be to look for the characteristic dependence on the sweeping velocity of the magnetic field and compare to the predictions of Landau-Zener theory. The difficulty is that features found such as the magnetic Foehn effect [10], where extra plateaux in the magnetization occur in the non-equilibrium response, may be described either as phonon bottleneck effects [11,12,13], i.e. that the bath does not relax to equilibrium on the timescale of the experiment, or by a dynamical effect of the system coupled to a bath that stays in equilibrium.

In what follows we shall look for extra features which could distinguish effects intrinsic to the small quantum system from such bottleneck effects.

3 Model for the molecular magnets {V 15 } or {Cu 3 }

In order to describe the reaction of the magnet to the external magnetic field, we have to precise the internal Hamiltonian for the molecular magnets. For systems (ii), to which the rest of the paper is devoted, we can write the Hamiltonian for three spin 1 2 moments

H 0 (t) = 3 i=1 (J i S i • S i+1 + D i • (S i × S i+1 ) + H(t) • S z i ) .
The system has 2 3 = 8 energy levels. The exchanges are chosen for triangular symmetry, i.e. the isotropic exchanges are equal and the three vectors defining DM interactions are determined by a single vector D and rotated around the three-fold symmetry axis [8]. Before discussing the dynamics, we shall discuss the static properties of H 0 . In Figure 1 we show its spectrum , i.e. with H(t) = H z e z constant for different values of H z . At large fields the spin 3 2 components have lowest energies and cross with the two degenerate spin 1 2 levels of opposite chirality. To make the degeneracies apparent a small chiral-breaking term has been added. We choose this additional term to be a Sen-Chitra interaction

H chiral = A chiral (H • e z ) S 1 • -1 -0.8 -0.6 -0.4 -0.2 0 0.2 0.4 0.6 0.8 1 Field (Units of J) -3 -2 -1 0 1 2 3 4
Energy (units of J) (a) Energy spectrum as a function of the magnetic field.

Both energies and fields are in units of J. (S 2 × S 3 ) [14]. The small Dzalyoshinsky-Moriya interactions give avoided level crossings. Below the spectrum we show the equilibrium magnetization at temperature k B T = 0.1J. It is clear that unless extremely low temperatures are available, little information on the details of the level crossing can be found, other than the points where levels cross, i.e. the value of the isotropic exchange.

In contrast to the relatively featureless equilibrium magnetization it will be seen that non-equilibrium observables such as magnetization are much richer and we now turn to the question of dynamics. We remark also that in such triangular-based spin systems, switching between different states involves more than just two states at a time; because of the chirality the crossings involve three (between spin 3 2 and the two chiral 1 2 states) or four (between the degenerate chiral doublet at H = 0). At the least a generalization of the Landau-Zener form is required. We remark that in certain cases the asymptotic transition probabilities for such multi-crossing may be reduced, via an "Independent Crossing Approximation" [15] to the calculation of two-level crossings. Because of the importance of avoided crossings we need a general theory that applies for multiple crossings with the details of the anisotropy [16]. For direct comparison with experiment it is also useful to have a general form of the time-dependent external field generated by the coils.

Environment: model and coupling to the magnet

In current experiments and probably future applications, the magnet can not be considered as a isolated system. It is indeed surrounded by an environment, responsible for relaxation and decoherence phenomena. In order to take into account those effects in our calculation, we have to define an environment explicitly. Unfortunately the true environment is not yet known precisely. We therefore focus here on a simple environment [17] modelled as an infinite set of bosonic harmonic oscillators:

H env = +∞ -∞ dω ωI(ω) b † ω b ω + 1 2 , (2)
We choose the spectral density I(ω) to be a power law,

I(ω) = ω α Θ(ω), (3)
with α = 2 (Super-Ohmic regime, as appropriate for a three dimensional phonon bath), and where Θ is the Heaviside distribution. Several additional hypotheses will be needed in the following. First we will supposed that the initial state of environment is a thermal state, that is to say that the environment is in thermal equilibirum with a thermostat at a given temperature T . Furthermore the environment is assumed to be Markovian, i.e. its correlation time is much shorter than the time scale of the dynamics. Taking these two hypotheses together implies a static environment, described at all times by the density matrix ρ env (t) ∝ exp (-βH env ) [START_REF] Blum | Density Matrix Theory and Applications[END_REF][START_REF] Breuer | The Theory of Quantum Open Systems[END_REF].

The coupling of the spin system to the bath is included with the term

H coupling = g +∞ -∞ dω I(ω)(b † ω + b ω )X (4)
The operator X is some combination of spin operators S i and couples the spin system linearly to the boson operators of the bath, b ω b † ω , with dimensionless strength g. It has sufficiently low symmetry that it can restore equilibrium from any initial state. e.g.

X = 3 i=1 (a i S x i + b i S y i + c i S z i ).
The coefficients a i , b i , c i differ from spin to spin, in order to induce transitions between states of different chiralities.

5 Bloch-Redfield approach to the reduced density matrix dynamics

The system (magnet + environment) is a closed quantum system described by the Hamiltonian

H tot = H 0 (t) + H env + H coupling . (5)
All the physical information of this closed system can be determined by the density matrix ρ tot (t). As the experimental set-up allows measurements on the magnet only, and not on the environment, we are interested in this magnet as an open quantum system, described by the reduced density matrix ρ(t) = Tr env [ρ tot (t)]. A naïve approach to study the magnetic dynamics would be to integrate the Liouville equation, coming from first principles, to obtain the total density matrix ρ tot (t) at all time, and then to perform the trace on the environment degrees of freedom.

However such an approach is essentially impossible to follow in practice given the high dimension of the Hilbert space. An approach to this problem, that is by now standard, is to make the additional hypotheses on the environment presented in the previous section, to obtain a dynamical master equation for the reduced density matrix. This perturbative approach dates back to the 1950's [START_REF] Bloch | [END_REF]21,[START_REF] Kubo | Hashitsume Statistical Physics II[END_REF]. We would like to stress that the equation does not come directly from first principles: it relies on additional assumptions whose validity needs to be tested for each particular system. For systems with a larger number of levels, the equations have been put in a compact form [8,24] to give the equation for the time dependence (in units where h = 1 )of the density matrix projected onto the Hilbert space ρ(t) of the molecular system (in our case the three coupled spins):

∂ρ ∂t = -i[H 0 (t), ρ(t)] -g [X, Rρ(t)] + [X, Rρ(t)] † . ( 6
)
If we define the instantaneous eigenbasis {|k, t } of H 0 (t) by

H 0 (t)|k, t = E k (t)|k, t , (7)
the operator R(t) is determined by its matrix elements k, t|R|m, t = I ω km (t) -Iω km (t) (8)

×n β [ω km (t)] X km (t),
where

ω km (t) = E k (t) -E m (t) and n β (ω) = (e βω -1) -1 . (9)
The external field H is taken to have arbitrary time variation in a single direction e x , e y or e z .

We shall now present results based on integration of the quantum master equation (6). In practice we integrate by fourth order Runge-Kutta approximation which leads to numerically convergent results, at least for weak coupling g and for times long enough to define several hysteresis loops. The hamiltonian must be diagonalised for each time step in order to define the matrix R(t). The time variation of the external field can be arbitrary but for our purposes we shall take it as cosinusoidal:

H(t) = H 0 cos(Ωt)e i , i = x, y, z, (10)
and as initial conditions ρ(t = 0) = exp(-βH 0 (t = 0)), i.e. the spin system in equilibrium with the heat bath at inverse temperature β = 1 kBT .

Numerical observations

We shall now make calculations of the observables for a model case in which we take a single component of the DM vector along the z-direction, D = D z e z . The purpose here is not to fit a particular experimental system, more to make general statements. We first show the three components of magnetization as a function of time. The initial condition is the equilibrium density matrix for the same temperature and the field H(t = 0) = -J. It is seen that at the relatively weak couplings that can be integrated numerically (g = 10 -3 to 10 -4 ) the magnetization "lags" the equilibrium magnetization. After one full oscillation the profile (in time) of the out-of-equilibrium magnetization approximately repeats, converging slowly towards some steady-state form. We remark that the period for the sinusoidal external field is 10 4 in units of J -1 . Returning to standard units, where h is not unity, this corresponds to a time of 5 × 10 -9 seconds for J=1 K. The information in Figure 2 can be represented in a form often used by experimentalists, i.e. as a hysteresis loop, where the magnetization is plotted against the external field. This we do in Figures 3(a) and 4(a). The difference between the two hysteresis loops is that in Figure and T = 0.2J. In the righthand panel, the details of the spectrum of the four lowest energy levels around zero field of Fig. 1, showing the crossing of the two nearly degenerate doublets. 3(a), the DM vector is parallel to the external field direction and in the second, Figure 4(a), it is perpendicular to the DM vector. In each case the magnetization is longitudinal, i.e. parallel to the applied field. The differences between the two orientations m z (H z ) and m x (H x ) are that the hysteresis loop is "fatter" when the field is perpendicular to the DM vector, but, more strikingly, that there are extra oscillations visible in m x (H x ) that are absent for m z (H z ). What is the difference between the two field orientations in terms of the spectrum of excitations? If we look at an enlargement of the spectrum of Figure 1 around zero field, as shown in Figures 3(b) and 4(b) this difference is apparent. For m x (H x ) there is an avoided level crossing at zero field with a minimum splitting whereas for m z (H z ) there is a crossing of levels. This avoided level crossing makes the hysteresis loop "thinner" as the lowest level smoothly evolves from one spin state to another. So what is the significance of the oscillations? For a two-level system formulated as a (pseudo-) spin in transverse field and time-varying longitudinal field, these transient oscillations [24] correspond to precession around an instantaneous axis which, near the avoided crossing, is perpendicular to the applied field. In other words these are simply Rabi oscillations in the presence of a timevarying gap. These oscillations are not periodic, but the characteristic frequency range is the gap in the avoided level crossing. This mixing of longitudinal and transverse oscillation is well known in "zero-field" NMR [START_REF] Kubo | [END_REF]. This suggests that the oscillations may be more visible in the transverse components of magnetization, i.e. the components perpendicular to the applied field. In Figure 5 we show the transverse magnetizations, for applied field perpendicular to the DM vector. It is seen that they are small except close to avoided crossings, where there are oscillations rapid on the time scale of the driving field. We remark that they are visible at a temperature (0.5J) well above the gaps induced by anisotropies. This leads to the suggestion for experiment that instead of looking exclusively at the shape of the hysteresis loop, as has been done most in the past; it may be more instructive to look at the Rabi oscillations. They may be most visible in the transverse components, as they are against a flat background. We remark that these oscillating components have been seen clearly in past numerical calculations [24,10,25] of the longitudinal magnetization but have attracted relatively little attention. We recall however from the theory of two-level systems that the decay of longitudinal components and transverse oscillations at a fixed magnetic field determines two characteristic time scales which give different information on the spectrum of the bath: in particular the transverse oscillations are sensitive to the zero frequency component of the bath [START_REF] Cohen-Tannoudji | Atom-Photon interactions[END_REF]. By analogy, measuring both longitudi-nal and transverse components one should, in principle at least, determine different properties of the spectrum of the bath.

We remark that for quantitative studies of the oscillations we should be a little more precise about what we mean by "transverse"; ideally we would take a component with vanishing mean. For the simple case we have shown here the ideal component is that which is perpendicular to both the applied field (parallel to e x ) and parallel to the DM vectors, i.e. m z (H x ). The component perpendicular to both the field and the DM vector m y (H x ), has small but non-zero values depending on the field. For noncollinear DM vectors on the three spins there may be no absolute separation of smooth and oscillating contributions; nevertheless the oscillations will always be stronger perpendicular rather than parallel to the applied field.

We note that these oscillations occur when the rotational symmetry is broken. This occurs if, as is the case in Figure 5, the DM vector and the external field completely break rotational symmetry, so that the phase transverse is determined by the (time-dependent) Hamiltonian [START_REF] We | [END_REF]. Oscillations also occur, (but are not shown in the Figures), in much smaller amplitudes of oscillations for m x (H z ); that is even when the Hamiltonian H 0 is symmetric around the field direction. This can happen because the coupling to the bath breaks the symmetry in our simulations. Whether this is true in a physical system or not, depends on the symmetries of the environment of the magnetic molecule. To restore symmetry in our formulation, while nonetheless allowing relaxation, we could include a sum of several terms of the form written for H coupling .

Conclusions

We have calculated the dynamic behaviour of weakly anisotropic triangular antiferromagnets, as could be seen in the molecular magnetis {V 15 } or {Cu 3 } subject to vary fast varying magnetic fields. Our simulations model in detail effects of tunneling including transient effects in a situation where Landau-Zener expressions are not sufficient to determine dynamics at arbitrary frequency and at finite temperature. This is especially so here are several levels contribute to the response because of degenerate chiral states on the triangle. We have argued that a useful characterization of the tunneling régime, useful would be the (non-periodic) oscillations in the magnetizations and, in particular, in the transverse components close to regions of level anti-crossing. This should yield more detailed information on the anisotropies causing level repulsion in molecular magnets, and the coupling to the bath, e.g. the value of the coupling g and the nature of the bath. The oscillations can persist (at least at weak coupling) up to temperatures well above the scale of the avoided level crossing. To illustrate this we have calculated hysteresis loops for a model in which there is a single component to the DM vector and the field is taken either parallel or perpendicular to this vector. We chose the simple case of a single component DM vector in order to illustrate the phenomenon. For this case there is only a single region of avoided crossing at zero field. In real systems such as {Cu 3 } all three components are present. There are then avoided crossings where, in the isotropic limit, the spin 3 2 cross the spin 1 2 levels H = ± 3 4 J, and oscillations will occur at all crossings.

We conclude that if one is interested in studying the physics at the scale of a single molecular magnet, it might be useful to study not only the traditional hysteresis loops, but also the transient oscillations, visible in the transverse component of the magnetization dynamics, as the first correction to the adiabatic limit.

  Equilibrium magnetization (in units of µB) in the direction of the field for T = 0.1J.

Fig. 1 .

 1 Fig. 1. (Color online) Spectrum of Hamiltonian H0 and equilibrium magnetization.

Fig. 2 .

 2 Fig. 2. (Color online) Magnetization as a function of time. The applied field is H (t) = Hz(t)ez (10). Hz(t) = -H0 cos(Ωt). The blue lines shows the equilibrium magnetization for each instantaneous value of the field. The parameters used are the following: H0 = J, Ω = 2π × 10 -4 J/h, Dz = 0.05J, A chiral = J/20 and T = 0.2J. The coupling g = 4 × 10 -3

  Hysteresis loops Mz(Hz).

  Detail of the spectrum.

Fig. 3 .

 3 Fig. 3. (Color online) Energy spectrum and dynamics of the magnetization parallel to the applied field, for H = Hz(t)ez parallel to Dzalyoshinsky-Moriya vector D = Dzez. The parameters are Dz = J/20, H0 = J, Ω = 2π × 10 -3 J/h, g = 4 × 10 -3and T = 0.2J. In the righthand panel, the details of the spectrum of the four lowest energy levels around zero field of Fig.1, showing the crossing of the two nearly degenerate doublets.

  Hysteresis loops Mx(Hx).

  Detail of the spectrum.

Fig. 4 .

 4 Fig. 4. (Color online) Energy spectrum and dynamics of the magnetization parallel to the applied field, for H = Hx(t)ex perpendicular to Dzalyoshinsky-Moriya vector D = Dzez. The parameters are identical to those of Figure 3: Dz = J/20, H0 = J, Ω = 2π × 10 -3 J h , g = 4 × 10 -3 and T = 0.2J. In the right hand panel the avoided level crossing of the doublet states at zero field.

Fig. 5 .

 5 Fig. 5. (Color online) Details of the oscillations in the magnetisation transverse to the applied field, perpendicular to the DM vector. Inset: Wave packet on a longer time scale. The parameters are Dz = J/20, H0 = J, Ω = 2π × 10 -3 J/h, g = 8 × 10 -3 and T = 0.5J. The avoided crossing is centred at t=250.


Sophie Dupuy-Chessa
email: sophie.dupuy@imag.fr

Eric Céret
email: eric.ceret@imag.fr

Gaëlle Blanco-Lainé
email: gaelle.blanco-laine@iut2.upmf-grenoble.fr

LEGO, PICTIONARY AND POKER: LESSONS LEARNT FROM GAMIFICATION FOR INFORMATION SYSTEM TEACHING AT UNIVERSITY

Keywords: Technical institute, information systems, games, engagement

Our context is the teaching of information systems at the license level of a technical institute. It requires technical knowledge as well as managerial one. In this context, an important part of the teaching concerns modelling of data that will be manipulated by the system and projects management for building systems. To facilitate learning and improving students' results, we investigated the Elaboration phase of the BSCS 5E Instructional Model as well as the Concrete Experience stage of Kolb experiential learning cycle and we experimented gamification in some of our teaching activities. This paper presents four case studies in gamification for information systems teaching: one of them is related to the learning of data modelling with a personalized version of the Pictionary, the two others concern project management with Legos and Poker. These case studies clearly show the usefulness of gamification in learning.

INTRODUCTION

We teach computer science at the license level of a technical institute. In this context, some of our teaching modules concern Information Systems (IS). Information systems gather together management and informatics techniques to efficiently identify, store and share information inside a company. They thus require technical knowledge as well as managerial one. In this context, an important part of the teaching concerns modelling of data that will be manipulated by the system and projects management for building information systems.

License students often feel that these notions are very difficult to learn because they require dealing with abstract concepts such as models and resources management. To facilitate learning and improving students' results, we investigated the Elaboration phase of the BSCS 5E Instructional Model [START_REF] Bybee | The BSCS 5E instructional model: Origins and effectiveness[END_REF] as well as the Concrete Experience stage of Kolb experiential learning cycle [START_REF] Kolb | The Kolb learning style inventory -version 3.1: 2005 technical specifications[END_REF] and we experimented gamification in some of our teaching activities. In this case study, the main objective was to increase students' engagement in learning by adapting games, which, in their original version, already promote collaboration and emulation. Contrary to several existing experiments, we chose to use traditional games that are well known by our students. We did not use computer games because our students are already highly involved in activities with computers for their technical training: in this perspective, computers are professional tools but not supporting tools. Our guess was that students needed alternative ways to access information. This paper presents three case studies in gamification for information systems teaching. It details the methods used with the gamification elements and specifies the lessons we learnt for each case study.

The second section of the paper presents a first case study, which uses the Pictionary game for teaching data modelling. The third section describes two case studies for project management. Finally, we discuss the lessons learnt from all these case studies before concluding and presenting perspectives.

PICTIONARY FOR DATA MODELING

Context and goals

The first case study takes place during the first year of license. Each gaming session concerns a group of 13 computer science students. It takes part of a teaching module about data modelling. Data modelling is a process of software engineering, which aims at identifying and describing data that need to be stored and manipulated by the software. For instance, a software managing students will deal with data such as the student's name, number, date of birth, degree. These data are represented graphically in diagrams such as the one presented in Fig. 1. Students are represented as a class (i.e. a structured piece of information) with a number as characteristic (attribute). Student inherit name and date of birth from the class Person. Student is linked through an association to the Degree class; the association carries the number of links between the two notions: for instance, the 1..* on the Student to Degree association means that a student can be registered in several degrees, i.e. one per year. Each relation between a student and a degree also carries information about the student's registration in this degree: this is represented by the class Registration: this kind of class related to an association is named an association class. A degree is composed of modules: this is represented by a special association named composition. This simple example illustrates the complexity of modelling with notions such as inheritance (between person and student), composition (between degree and module) or association class (e.g. registration).

Fig. 1-Simple example of data model

Several approaches can be used for data modelling, particularly the Unified Modeling Language (UML) [START_REF]OMG Unified Modeling Language (OMG UML) v2[END_REF], which is a standard. It proposes models for representing software functions, data, architecture… The learning of UML require 1) to make abstractions so that to identify the main concepts in the "universe" the software is dealing with; 2) to describe these abstractions graphically, following the rules of the UML language, 3) to understand the technical problems in order to describe the corresponding solutions. So modelling is a very difficult task, particularly while considering subtle notions like inheritance or composition. Moreover as UML models are not "runnable", most students do not appreciate it. Their emotion varies from boredom to indifference even if some of them show interest.

We introduced a game to make modelling more engaging and to encourage students in using it. It takes place before the exam in the application phase of learning for checking whether students have acquired some automatic reflex in modelling. We experimented the game approximately 10 times.

Game description

The case study relies on a personalized version of the Pictionary1 , a game originally promoting speed and collaboration. In Pictionary, a team has to identify the word drawn by a teammate within a minute, sometimes challenging other teams.

In our modelling context, students have to create models instead of drawings. But the game rules are identical. There are 4 teams of 3 or 4 players. At each turn, a team takes a card; one player plays the role of drawer and has to make a UML model corresponding to the sentence written in the card. In the traditional Pictionary, there are 4 kinds of subjects: person/place/animal, object, action, difficult and "all play" (see figure 2a). In the UML version, the subjects are related to the different kinds of models. There are class diagram, use case diagram and sequence diagrams, as shown on figure 2b. We also keep the "all play" subject.

The model, as shown on figure 3, is realized on a paperboard so that all players can see it. If one other member of the team says the expected sentence, the team wins and can go some steps forward. There are some specific squares on the game board for challenges where all the teams model at the same time. In this case, each team uses its own sheet of paper to draw its model. The fastest one wins the turn. The winner of the game is the team that arrives at the final square.

During the game, at the end of a turn, the teacher can correct very quickly some models or explain some good solutions. However to keep the game spirit, students are not supposed to take notes or corrections.

The gamification elements we used here are 1) small challenges with time-pressure and competition so as to progress and to arrive first at the end of the game and 2) a reward i.e. a packet of sweets for the winners.

Lessons learnt

First, lessons learnt concern how to practice with UML Pictionary. The main difficulty is to find the right balance between gaming and learning. On the one hand, to encourage gaming and engagement, teachers must limit their interventions to the minimum; teacher's interventions can indeed lead students to wait for a given solution. On the other hand, for encouraging learning, they should correct models and let students take notes about the discussions and correction. So during the game, we decide to quickly correct models, if necessary, just to give an idea of one or another solution. Students are not asked to take notes. They must listen and understand the correction.

Secondly, we have learnt lessons about the pedagogical aspect of the game. The first lesson is that students appreciate the game and really play it. One of them even cheated to win! So gaming really improves engagement.

It is a pleasant way of reviewing concepts for the exam. As a matter of fact, the game is appropriate for players who know UML. The idea is to apply the notions quickly and to get to the key point. It allows students measuring their level of acquisition in UML and confronting their knowledge. For instance, sometimes students discussed about the choice of one notion rather than another (e.g. an association versus a composition), each one explaining to the other one what he/she has understood about the notion. The teacher is here to (eventually) correct and complete explanations.

The last benefit was that students understood how crucial it is to make clear and understandable models. Using the wrong notation, making an error in the choice of model component directly leads the teammates to misunderstand the model and makes the team lose. Therefore, all students were highly involved in making "good models", leading them to refine their understanding of the differences between the notions.

GAME FOR PROJECT MANAGEMENT

This section presents two case studies for learning software project management. One of them used Legos as a mean to practice for knowledge acquisition. Legos are used for introducing development life cycles. In the other game, Legos are used for resources management, especially for estimating workloads and risks inside projects. In the same manner, Poker game is used for helping to understand resources management. The design of the session was largely based on the work proposed by Alexey Krivitsky [START_REF] Krivitsky | Lego for extended Scrum simulation[END_REF]. Each case study is described in a following subsection.

Legos for development life cycles

Context and goals

The first case study takes place at the second year of license. It concerns a group of 17 students with background in computer science and statistics. It takes part in a teaching module about web development. In this module, students will have to build a website in pair. In order to help them organizing their project, the module starts with an introduction of development life cycles.

A life cycle is a framework of processes and activities that may be organized into stages. It also acts as a common reference for communication and understanding of the project. Many different life cycles are used in computer science. To make students understand their differences, we use two opposite cycles:

• the Waterfall model [START_REF] Royce | Managing the development of large software systems: concepts and techniques[END_REF], which is linear (Fig. 4a). One stage follows another one and there is no feedback to a previous stage. It is based on the creation of documents from requirements analysis to design before starting activities like implementation or testing.

• An agile cycle, which is iterative and incremental (Fig. 4b). The Agile Manifesto [START_REF] Fowler | The Agile Manifesto, Software Development[END_REF] defines twelve fundamental principles such as "customer satisfaction through early and continuous delivery of valuable software" or "welcome changing requirements, even late in development".

Here we use the SCRUM cycle [START_REF] Schwaber | SCRUM Development Process[END_REF]. SCRUM focuses on user needs and suggests a short iterative development cycle that can be adapted according to changes occurring in the customer needs. Once a global list of features is created (Product Backlog), one or several of them are realized during an iteration. The complete software is produced thanks to several iterations. Changes can be made at each iteration.

The learning of life cycles usually requires a strong experience in projects that students do not have. It is very difficult for them to imagine how a software (and more globally a product) can be built by several persons in a given delay. It makes them feeling confused.

We introduced a game for helping students acquire some experience in project building and to make them understand notions that are not understandable without some practice. We experimented the game with two groups of 17 students.

Game description

After a short introduction to life cycles goals and some vocabulary, we proposed students to play two games with Legos in groups of 4 to 6. The goal was the creation of a set of buildings, constituting a whole infrastructure, in Legos. There were two sessions of 90 minutes, one with the Waterfall cycle and one with the SCRUM cycle. The groups could not change between the two sessions.

At the beginning of each session, a short presentation of the cycle to apply and of the goal of the game were given. Then groups had to follow instructions to build their complex. They were three phases of 15 minutes.

The first session concerned the Waterfall cycle. Students were asked to build a holiday village. During the first phase, they had to identify the list of buildings and some construction constraints. During the second phase, they had to specify with drawings or schemes their village. During the last phase, they built the village with Legos. Finally, they presented their work to the other groups.

The second session used the SCRUM cycle. Students had to build the ideal university campus. During the first phase, they had to identify requirements. During the two other phases, they had to build the campus. As changes are welcome in Agile cycles, the teacher made comments during all phases for pointing out problems or refining requirements.

After the two sessions, a 2 hours debriefing session allowed students to discuss about their experiences and to identify the drawbacks and advantages of each cycle.

The gamification element we used here is mainly small challenges with time-pressure. They also enjoy seeing other groups' constructions.

Lesson learnt

This case study was realized at the very beginning of the second year of license. It constituted the first lectures in computer science for this year. So they were very important for the relationship between teacher and students. It allowed all of us to start the year in a pleasant manner. Students really appreciated it. They were curious and enlightened by this new way of teaching. They were engaged in the sessions and tried to capitalize on the Lego experiences in order to have a critical analysis about life cycles during the debriefing. The debriefing session was a place of exchange and sharing, which brought unexpected discussions about concepts. The Lego sessions helped students to understand notions that are not understandable without practice. First, students understand in deeper details each cycle. For instance, while applying the Waterfall cycle, a group wanted to add a new building at the last phase i.e. during the building of the holiday village. But adding a new requirement at this stage is not possible in a Waterfall cycle. In the SRUM session, one group has built an amusement park inside the campus without asking the client if he/she wants it. This is not possible in an agile cycle where stakeholders must be part of any decision and give their opinion before developing new features. The experience showed students what is possible and not possible in each development cycle by doing the parallel between building Lego villages and software.

It also allowed them to identify some drawbacks or limits of cycles. For instance, one group did not succeed in finishing the building of their holyday village whereas the whole plan was ready (Fig. 5a).

The lack of time at the end of the project is a well-known problem in the Waterfall cycle, which was clearly identified by students. In the same manner, students succeeded in identifying advantages of each cycle. For instance, the fact of iterating on a construction is clearly seen as an advantage of agile cycle, but they also identified that it can lead to a bad global architecture if this is not considered at the beginning of the project (Fig. 5b). In conclusion, the sessions really helped student in understanding the cycle principles and their differences. This cannot be learnt during a theoretical lecture.

Legos and poker for project management

Context and goals

The first year of computer science training includes a module about software project management. This module aims at teaching students how to work in an efficient manner in the context of software projects. Students should acquire the basic skills of a software project leader: they must be able of organising and planning successful projects as well as taking into account and monitoring all the resources and constraints of the project, in accordance with costs consistency, deadlines and quality.

The module organization is classic: it includes the presentation of the concept of project, of the various stakeholders, of the activities related to project management including the choice of software development life cycles and workloads estimation. We will call a development method the process that gathers the use of a life cycle with resource planning such as workloads estimation.

In this context, two activities based on gamification are used: poker for estimating workloads and Legos for organizing and realizing the sequences of stages. In the previous case study with Legos, gamification were used for understanding stages sequencing (i.e. development life cycles), not for the resource planning as it is done in this experiment. Gamification replaces a more traditional lecture on principles and techniques about these project management activities.

As for the previous case study with Legos, the main difficulty of this module is related to the students' lack of business experience. The goal of gamification was to make practices and challenges of project management more real, going beyond the experience feedbacks delivered by professionals (in videos, for example). The use of games, here the Legos and poker, illustrates the concepts in order to show the application of project management principles and their limitations.

As in the previous experiment with Legos, small challenges with time-pressure are the elements of gamification.

Game description

The game took place over a 2 hours session. It followed:

• a lecture about software development life cycles in general,

• a lecture on agile development methods and especially the presentation of SCRUM, starting from Henrik Kniberg video realized in 2012, "Product Agile ownership in a nutshell" 2 .

The teacher, in a SCRUM logic, took the role of product owner (i.e. the customer), who is typically a project key stakeholder. The Users Stories i.e. the expression of requirements with scenarii were simple, and based on the classical format of the construction of a city. The requirements were used for workload estimation using the poker, and for the organization and realization of stages sequences (names sprints in SCRUM) using Legos.

Poker, already used in the context of agile development methods, allowed highlighting the importance of communication while estimating workloads. This method, described by James Grenning [START_REF] Grenning | Planning Poker or How to avoid analysis paralysis while release planning[END_REF] is based on the comparison of estimations by different persons who argue their motivations. As the method claims that the bigger the task to realize the fuzzier the estimation, it uses the Fibonacci sequence for evaluations: evaluators have to choose a number of working days within the possible values defined by the Fibonacci sequence (i.e. 1, 2, 3, 5, 8, 13, 21, 34, 55, 89).

The teaching session lasted 2 hours and was structured in two phases:

• Task definition, planning and sequencing: during this phase, Poker was used for load estimate; • Iterative construction: here, Legos allowed students to build and refine their city. At each iteration, they had to decide which buidings must be built or changed during the iteration. Some of them chose to start the city by public infrastructure like hospitals and schools while others preferred residential area. At the end, they are supposed to propose a complete city. But it was not always the case due to time pressure.

The first phase, in a predictive sense, aimed at defining and delimitating the project, as well as defining the work organization. The second phase addressed the realization of the defined project. We have imposed to follow an iterative and incremental process (Fig. 6).

In the sprints reviews (at the end of each iteration) and at the end of the session, a debriefing was done.

Lesson learnt

From the use of Poker for workload estimation and Legos for project management, several observations can be done. The introduction of a game session caused a break in the teaching pace and methods and kept the students' attention and curiosity aroused.

This gaming session succeeded in:

• Establishing links between previously presented concepts, like workloads estimation, development cycle or team organization; • Giving meaning to some definitions related to development methods, such as the concepts of increment and iteration; • Highlighting the importance of communication in the context of software project, not only between product owner and project team but also inside the project team.

It was also used to introduce, in the stages sequence, the concepts that were discussed in more traditional ways, especially the theme of analysis and risk management.

Students enjoyed this way of practicing, they were more engaged in learning and they interacted more with the teacher even after the game. However, as students of different ages were involved, we noticed that mature people are less prone to play for learning.

CONCLUSION AND PERSPECTIVES

Contrary to new practices, which use computer games for learning, we used traditional games for teaching computer science. Our experiences clearly show the usefulness of gamification in learning.

Students are now able to understand and manipulate difficult and abstract concepts introduced in games. Playing and working as a team led them to share knowledge. We also noticed a very good students' engagement in most cases.

Including gamification for helping students to learning subtle notions has been efficient: it first increased students curiosity and engagement and, thanks to concrete experience, they could make a first idea of the notions, that facilitated the acquisition of theorical concepts.

One key point is that both parts have to "play the game", especially the teacher, who needs to be aware that the game spirit is important and has to go beyond his casual behaviour. For students, engagement is easy to obtain most of the time. However they can call the game into questions if they Fig. 6 -Game session organization have a too traditional vision of teaching. It is especially a problem for elder students. They have to accept that playing is also a way of learning.

We would like to continue our experience in traditional games for teaching computer science. First of all, we plan to modify the Pictionary questions for adapting the questions to our specific teaching program and for introducing levels of difficulties in questions. We also think about adding new gaming sessions in our practices. Especially, we think that games would be useful for introducing modelling process. By increasing the gaming frequency, we can also test either students get used or if they keep their engagement.

Fig. 2 -Fig. 3 -

 23 Fig. 2 -Examples of (a) a classical Pictionary card (on the left) and (b) an UML Pictionary card (on the right)

Fig. 4 -

 4 Fig. 4 -(a) Waterfall cycle (on the left) and (b) SCRUM agile cycle (on the right)

Fig. 5 -

 5 Fig. 5 -(a) Unfinished holiday village (on the left) and (b) Bad global architecture without space between buildings (on the right)

http://people.irisa.fr/Francois.Schwarzentruber/mit2_cvfp_2012/uml_pictionary_cards.zip

please, see www.youtube.com/watch?v=502ILHjX9E

ACKNOLEDGEMENTS

This project has been supported by the French government's "Investment for future" program IDEFI (ANR-11-IDFI-0031) (initiative for excellence in innovative training).


Nicolas Hili
email: nicolas.hili@cea.fr

Christian Fabre
email: christian.fabre1@cea.fr

Sophie Dupuy-Chessa
email: sophie.dupuy@imag.fr

Dominique Rieu
email: dominique.rieu@imag.fr

A Model-Driven Approach for Embedded System Prototyping and Design

Keywords: Embedded System, Process, Iteration, Prototyping

Embedded System (ES) development complexity is increasing. This increase has several cumulative sources: some are directly related to constraints on the ES themselves (dependability, compute intensive, resource constraints) while other sources are related to the industrial context of their development (fast prototyping, early validation, parallelization of developments). Although several Model-Driven Engineering (MDE) processes have been proposed for ES development, most of them are not completely formalized. This has several drawbacks that prevent their use in prototyping where iterations need to be short and focused. Incomplete formalized processes tend to be sidestepped in these situations where quick results are expected to be obtained with limited effort.

In this paper we propose a MDE-based process for ES development. This process precisely defines the development tasks and their impact on the models throughout development. In particular we define iterations width and depth for the process that allow for a fined-grained and consistent planning of developments. The short and well defined iterations characterized by the process reduce the gap between rapid prototyping, ad-hoc methods and regular development processes.

I. INTRODUCTION

Over the increasing complexity of Embedded System (ES) development, more and more developers turn to Model-Driven Engineering (MDE) to foster ES design [START_REF] Broy | The 'Grand Challenge' in Informatics: Engineering Software-Intensive Systems[END_REF], [START_REF]Seamless model driven systems engineering based on formal models[END_REF]. MDE promotes the use of models to abstract all or part of the system being considered. It permits to visualize ES through different viewpoints and extract essential properties to its modeling. Additionally, MDE provides techniques to perform from executable models a number of static analyses, performance analyses, simulations and so on. It also offers a way to separate design from implementation which is particularly well appreciated when designing ES composed of an application hosted by a platform.

Complexity of ES design is emphasized by the needs of early error detection and regular feedbacks to guaranty that the system is conform to its specifications. One of existing techniques to ensure specification validation is system prototyping [START_REF] Kordon | An introduction to rapid system prototyping[END_REF]. Prototypes permits to assess the fulfillment of the specifications while giving a concrete view of the system under development and the design process as well [START_REF] Tessier | A component-based methodology for embedded system prototyping[END_REF], [START_REF] Hugues | Using mde for the rapid prototyping of space critical systems[END_REF]. However, prototyping could be incompatible with modelbased methodology where time spent to create the models at several abstraction levels might be considerable. Several aspects of MDE contribute to reduce the gap between modelbased and prototyping-based methodologies. The use of model transformation permits to transform abstract models to more concrete ones which ensures the following of the process in a continuous way and the use of code generation techniques ensures to generate high quality and robustness application code and reduce time spent to debug and validate the produced software and hardware code.

Despite the acceptance of MDE for ES design, few of ES designers exploit it to formalize and automate ES processes. They are often defined ad-hoc and barely formalized in terms of models. Formalizing them could plan and foster their executions, with high confidence and help to reduce the gap between MDE and prototyping. This paper presents a modelbased process for embedded systems called HOE 2 [START_REF] Hili | Efficient Embedded System Development: A Workbench for an Integrated Methodology[END_REF]. This process is formalized at very fine-grain thanks to activity and behavior diagrams so it exhibits development tasks and their impact on the models produced during the development. The fine-grained definition of the process allows a project manager to organize quick iterations to enhance the prototyping. This paper is structured as follow. Section II is aimed to give a comprehensive view of the state of the art; section III introduces HOE 2 , a model-based process for ES development while section IV shows how it is possible to reduce the gap between MDE and prototyping; section V presents the benefits in terms of project monitoring and development planning; we present the development of an embedded system case study in section VI to show the impact on a prototypingbased development compared to a regular one; finally, we summarize our results and give future directions in section VII.

II. STATE OF THE ART

This section is structured through two axes. The first one addresses the process modeling languages an their specificities. The second axe addresses model-based approaches for embedded system design.

A. Process Modeling Languages

In software engineering, a number of languages were proposed to model processes [START_REF] List | An evaluation of conceptual business process modelling languages[END_REF], [START_REF] Ellner | eSPEM -a SPEM Extension for Enactable Behavior Modeling[END_REF]. The undoubtedly wellknown is the Unified Modeling Language (UML) [START_REF]Object Management Group, Unified Modeling Language Superstructure 2[END_REF]. UML provides a few concepts that can be used to model processes. Those are assembled inside the Activities package. It proposes several concepts like Activity, ActivityNode, flows (ControlFlow and ObjectFlow) to model product-oriented and activity-oriented flows. Among another well known processes, we can cite Business Process Model and Notation (BPMN) Metamodel [START_REF] Omg | Business Process Model and Notation[END_REF] and Software & Systems Process Engineering Meta-model (SPEM) [START_REF]Software & Systems Process Engineering Meta-Model Specification[END_REF]. BPMN is a process modeling language focusing on a clear graphical notation understandable by all the participants of a process, from the analyst, to the designer, including end users. SPEM is a process modeling language based on a MOF 2.0-based metamodel that essentially focuses on software systems processes.

A number of model processes was proposed to address industrial concerns related to rapid development and prototyping. The Spiral model [START_REF] Boehm | A Spiral Model of Software Development and Enhancement[END_REF] and the Rapid Application Development (RAD) [START_REF] Martin | Rapid Application Development[END_REF] are such process models. They focus on short iterations and prototyping development. Prototyping helps to reduce risk and improve quality of the desired system. Another approaches for rapid development are Rational Unified Process (Rational Unified Process) [START_REF] Jacobson | The Unified Software Development Process[END_REF] and Unified Software Development Process (USDP) [START_REF] Ibm | Rational Unified Process: Best Practices for Software Development Teams[END_REF]. They are usecase-driven processes where usecases are prioritized and define iterations in order to cover the highest risks first. Each iteration ends with the production of prototypes.

B. Model-Based Embedded System Design & Prototyping

A number of system and embedded system design methods address prototyping issue though the use of models and incremental processes. ACCORD/UML [START_REF] Tessier | A component-based methodology for embedded system prototyping[END_REF], [START_REF] Phan | Languages for system specification[END_REF] is an embedded system design method applied to the automotive area. It relies on an extended version of the UML language based on the definition of an UML profile to enable real-time embedded system development. The ACCORD/UML process focuses on three phases: analysis, design and implementation, it is defined as iterative and continuous with possible backwards. The approach promotes an iterative development to build a system by increments. In [START_REF] Gérard | Using the model paradigm for real-time systems development: Accord/uml[END_REF], the authors give an overview of the ACCORD/UML using the modeling artifacts defined in the SPEM profile. They define three participants, among them the prototyper. A prototyping phase allows the prototyper to build a prototype model. While the process is rather textually described, their is no real use of executable process modeling language to enact the process, establish a project monitoring and reduce the gap between MDE and prototyping. MOPCOM [START_REF] Koudri | Using MARTE in a Co-Design Methodology[END_REF], [START_REF] Aulagnier | SoC/SoPC development using MDD and MARTE profile[END_REF] is a co-development method for system on chip design. It is based on the Model-Driven Architecture (MDA) techniques, especially on the separation between platform independent and specific models. The MOP-COM language is based on both MARTE [START_REF] Sabetta | UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded Systems[END_REF] and SysML [START_REF]Systems Modeling Language Specification[END_REF] languages. On process side, MOPCOM proposes a top-down flow through three abstraction levels. At the end, software and hardware synthetizable code are generated. We can compare the MOPCOM process to the Y life cycle from Capretz [START_REF] Fernando | Y: A New Component-Based Software Life Cycle Model[END_REF]. More precisely, the process is built upon three successive Y life cycles enabling parallelism. However, the process is pretty unclear and imprecise, no participant is identified, neither the possibility of iterations, requirement-guided development, etc.

Behavior, Interaction, Priority (BIP) [START_REF] Basu | Rigorous component-based system design using the bip framework[END_REF] addresses the design of system based on model and component oriented approach. It permits to build hierarchical and composite models in which each atomic component is considered in terms of behavior and interactions with other components. The formal language ensures that the design and assembly of atomic components is correct-by-construction. BIP embeds a product and activity-oriented process. In [START_REF] Basu | Rigorous component-based system design using the bip framework[END_REF], the process is illustrated by a flow diagram with input and output models, iterations and activities, but is not formalized in an executable process modeling language.

Embedded system model-based approaches usually propose flows that cover all or part of the life-cycle of the system under consideration. Those flows are composed of many steps involving modeling at different abstraction levels and occasionally propose consistent rules to go down throughout the development process. Some of them explicitly propose prototyping activities, and process automation through consistent transformation rules to go down throughout the development process and thus foster the prototyping. However, none of them proposes a clear formalization, preventing a method user to know when the model under development at one abstraction level is ripened enough to initialize downstream activities on the flow. Such formalization would leverage the vagueness and imprecision around processes and would allow a project manager to have a big picture of project planing and task organization adopt a prototyping strategy.

III. THE HOE 2 APPROACH

In this section, we present the HOE 2 approach. HOE 2 is a model-based approach previously proposed in [START_REF] Hili | Efficient Embedded System Development: A Workbench for an Integrated Methodology[END_REF] and stands for Highly Heterogeneous Object-Oriented Efficient Engineering. HOE 2 embeds both a collaborative process and a common language for application and platform based on useful concepts of objects, association, state machines and message passing. Fig. 1 gives a partial view of the HOE 2 process. Not discussed here, but the HOE 2 process is platform-based design [START_REF] Sangiovanni-Vincentelli | Quo Vadis, SLD? Reasoning About the Trends and Challenges of System Level Design[END_REF] as the platform design flow is composed of the same four phases as the application design one. This aspect allows designers to iterate over several stacked platforms, giving to the process its fractal nature [START_REF] Hili | Model-Based platform composition for embedded system design[END_REF].

A. Requirement Phase

The requirement phase permits to formalize informal specifications of the system. These specifications describe functional as well as technical requirements and serve as inputs to the two development flows: functional requirements for the application development flow and technical requirements for the platform one. During this phase, the requirement is formalized in terms of actor and usecases organized according to their causality (i.e. their importance regarding the system under development -possible values are primary or secondary) and of scenarios which are prioritized through their nature (nominal or error) and their importance. Each scenario represents the smallestgrain of the requirement definition. All the further activities will endeavor to fulfill the requirements by keeping consistency and compliancy with the scenarios of the requirement model.

B. Analysis Phase

During the first phase, a black box system (an application for the first flow and a platform for the second one) is defined in terms of requirements. During the analysis phase, this system is opened and detailed in terms of communicating objects and object behaviors. Behaviors are captured with state

(2)

Application Development Platform Development (1) Introduction of platform's topology (2) Introduction of Platform's implementation rules

C. Design Phase

During the design phase, a first topology of the platform is introduced in the application development flow. This topology is limited to the definition of the world -or execution domainof the platform. The distribution activity involves distributing the application objects over the worlds of the platform. Again, compliancy from the requirements must be ensured during the distribution activity.

D. Implementation Phase

The implementation phase is the last step before code generation. During this phase, a complete description of the platform feeds the application development flow. It embeds implementation rules to define how objects are concretely implemented on the platform. The implementation activity involves defining which implementation rules should be used for each object.

The HOE 2 process is distinguishable from other processes and development life cycles by its many aspects. Two concurrent flows allow developers to design the application and the platform that hosts it. Both flows are independent and concurrent but the HOE 2 process defines two synchronization points to gradually introduce the platform model inside the application. The platform analysis model defines the platform in two steps and offers a smooth implementation of the application on the platform by defining 1) where the object should be located and (design phase) and 2) in which way they are concretely implemented (implementation phase). This smooth implementation permits a rapid feedback from the application development to the platform one.

In HOE 2 , organization of activities is guided by the formalized requirements during the first phase. That means that all the tasks producing new elements on a model must be performed in accordance of one or more scenarios. This aspect addresses prototyping in the sens of a project manager can organize quick iterations to cover only partial widths of the requirements and go down through the four phases in order to design prototypes with minimal effort.

Tool Support

The HOE 2 process is partially supported by a dedicated tool named CanHOE2, a standalone product based on Eclipse. It addresses several collaborative aspects like model exchange and synchronization, and uses Git as a backend.

IV. MODEL-DRIVEN ENGINEERING AND PROTOTYPING

To reduce the gap between MDE and prototyping, an informal definition of the process as illustrated in fig. 1 is Fig. 2. HOE 2 Process Activity Diagram not sufficient and tends to be sidestepped. Our proposition is based on the adaptation of the UML2 metamodel to give a stronger definition of the modeled requirement-driven process. Other works also deal with requirements [START_REF]Systems Modeling Language Specification[END_REF], [START_REF] Blouin | Defining an annex language to the architecture analysis and design language for requirements engineering activities support[END_REF].

We propose in this section an activity package to model activities, tasks and their associated input and output models. Those models need to be defined at the M2 layer (metamodel) of the OMG pyramid so they can be tightly coupled with the HOE 2 product models. To do so, we propose an Activity package as an extension of the UML2 activity metamodel. Fig. 2 models the HOE 2 process in terms of activities and input / output objects. The first input of the process is the informal specifications of the system.

The Activity package we propose in this section is part of the HOE 2 project management three-layers metamodel illustrated in fig. 8. The two bottom layers are not addressed in this section and will be the subjects of section V. In the activity package, we model the four HOE 2 process main activities and detail them into a number of dedicated tasks. For each phase, we list used and produced models, give a state representation of them, detail the requirement to initialize each phase and decompose the activity into small-grained tasks. We further formalize each task in terms of input and output model elements and of pre and postconditions. This section is structured in three parts. First part gives a dynamic vision of the HOE 2 models throughout the execution of the process while second and third parts focus on the description of the HOE 2 activity package that enables to bridge the gap between prototyping and regular development processes. We propose in this part both a structural and a behavioral modeling of the HOE 2 models. Fig. 3 depicts the taxonomy of HOE 2 models produced throughout development. Each of them specializes the Model UML meta-class. In the INITIALIZED state, the model is built from upstream models. After initialization, a first modeling activity has to be performed. After the activity is performed, the model under development evolves into the MATURED state. This intermediate state means that the model is not fully complete, but it reaches a sufficient degree of ripeness to initialize the next phase. In the case of the implementation model, code generation can be performed from it. Finally, a model is marked as COMPLETE during the closing activity. This activity is performed by the project manager when he or she considers the model under development is complete. Except for the first one, each model may be considered as complete when each modeling activity performed on it contributes to satisfy all the requirements formalized in the upon requirement model.

Behavior modeling of HOE 2 models brings some benefits. We clearly define when a phase can be initialized from upstream models. The intermediate MATURITY state enables a project manager to initiate the next phase before the model is completed. This facilitates the development of prototypes without covering the whole specified requirements. The second benefit results from the fact that state preconditions can be applied to automate the successive flow of activities with a high confidence in the consistency of it. While modeling activities need to be handworked, initialization and completion ones can be automated or at least assisted. To enable it, we define constraints as precondition for each initialization and completion activity. Additionally, we define for each initialization activity a set of transformation rules that can be executed to fill up the initialized model with data collected from upstream models. Code generation rules are also defined to produce code from the last model of the HOE 2 flow.

B. Activities

To model the HOE 2 activities, we chose to extend several concepts defined in the UML Activities package from the UML metamodel. Fig. 5 illustrates the fundamental concepts of the activity package at metamodel level (M2) we propose. An activity is a set of tasks: initialization, closing and modeling tasks. We extend the Activity and ActivityNode UML metaclass. A task may also have two constraints: a precondition and postcondition. The precondition is based on input model states. The postcondition defines into which states must evolve the output models. We chose to model an activity diagram at model level (M1) for each phase of the HOE 2 process.

C. Tasks

In HOE 2 , we define a task as an atomic modeling activity. Task can be manual, automated or assisted. In Fig. 5 a task may define two constraints, one precondition and one postcondition. Additionally, it references a set of input and output models as well as model elements.

Once we have modeled the four models and the four activities, we can further define a taxonomy of tasks for each activity. First, we model the activity with UML activity diagram. In Fig. 2, we detail the requirement activity by decomposing it in a number of tasks. Each task can accept inputs and produce outputs. For each input and output, we may define one or more states between square brackets. We decompose the requirement activity into three tasks (see Fig. 7). task 1 (Initialization): First task initializes the phase. The output is an INITIALIZED requirement model. It only contains the system without any usecase or actor using the system. task 2 (Formalization): Second task formalizes the requirement. it can be decomposed into two subtasks. The first subtask expands the current requirement formalization. It allows a developer to add new usecases, actors, and at least one nominal scenario per newly created usecase. When this subtask is realized for the first time, i.e. the model is INITIALIZED, the developer needs to define at least one primary actor executing one primary usecase, and the usecase must own at least one Fig. 6 depicts the five modeled requirements tasks from the activity package. Fig. 7 focuses on the definition of the expanding task. It precisely references which models and model elements serve as input of the task and which ones should be created during the task. For this purpose, we subset the four references depicted in 5 between the Task and both UML Model and Classifier meta-classes. In the case of the expanding task, as the system is created during the initialization task, it cannot be recreated during the expanding one. Additionally, the expanding tasks must verify preconditions and postconditions. Listing 1 and 2 are example of pre and post conditions. The precondition checks if the model is in initialized state, by verifying whether the model is composed of a system. No other verification is performed since the model can either be in INITIALIZED as well as MATURED to perform this task. The post condition checks if the system is matured.

By refining this work for each task, we get a complete description of the process. This contributes in rising confidence in the consistency of the flow and accelerating the development by preventing a developer to deviate from the process.

V. PROJECT CHARACTERISTICS & MONITORING

This section focuses on project monitoring concerns. Fig. 8 depicts the HOE 2 the project management metamodel built Fig. 7. Expanding task in the HOE 2 Activity Package on three package. The bottom package represents the participant to the process. In HOE 2 , we identified two participants, the project manager and the developer. The project manager is in charge of creating new tasks and assigning them to a developer. The developer's activity consists of realizing tasks assigned by the project manager. In HOE 2 , the developer can be either the application or the platform developer. The Project package contains concepts for project monitoring concerns. We present two concepts. Project to precisely characterize the project aimed at designing the system under study and Iteration to allow the project manager in charge of the project to organize tasks into a set of ordered iterations.

The ability of organizing tasks into iterations confers benefits for project monitoring. It is easy to create a consistent planning of developments. The left side of Fig. 9 shows such an organization. Horizontal axe illustrates the requirement width. It symbolizes the ordered set of scenarios that need to be satisfied during the four phases of the HOE 2 process. Vertical axe illustrates the process depth, i.e. the four phases of the HOE 2 process. Each square can be colored with proper color related to the iteration. The right side of Fig. 9 shows another task organization that enhances prototyping. Both sides of Fig. 9 illustrate the tradeoff project manager can make to either favor prototyping with quick vertical iterations or large An abstract view of the Face Tracker system behavior is provided Fig. 10. Initially, the bracket and hence the camera, are in an initial position and the camera is inactive. When the PIR sensor detects a presence -See transition  -the camera becomes active. The video stream is sent to an algorithm that performs face detection. When a face is detected, the system computes the Cartesian coordinates of the face on the picture. Those coordinates are then translated into spatial coordinates and the system orientates the bracket to center the face on the pictures. If the face moves out from the picture, the system stays in the same position. When the PIR sensor does no longer detect a presence -See transition  -the camera becomes inactive and the system returns to its initial position.

Tab. I and II show fragment of lists of usecase and scenario formalizing the requirements. A strategy favoring prototyping can be chosen by selecting appropriate scenarios and develop through the depth of the process once, and planning another scenario fulfillment during a second iterations. For instance, a project manager can ignore scenarios about switching between two modes and prioritize usecases related to face detection and recognition in two first iterations. During the third iteration, it can choose usecase related to camera orientation and finally, the last iteration for manual / automatic mode switching.

VII. CONCLUSION AND FUTURE WORKS

In this paper we present the HOE 2 process and its formalization language. We show how, by adapting the UML activity metamodel, we are able to define a very small-grained set of activities and tasks with clear inputs and outputs. This allows us to provide concepts for project characterization and monitoring -possibly automatic. Our contribution shows benefits in terms of organization of tasks and produces consistent planning by means of explicit dependencies across tasks. We think that this is not only applicable to regular development but also to prototyping, where shorter cycles and efforts are expected to produce very targeted results. The dedicated tool CanHOE2 currently supports only the first phase of the process. Future work will address the formalization of remaining activities and tasks of HOE 2 , the modeling transformations rules for those that can be automated and the extension of CanHOE2 for their support.

Fig. 1 .

 1 Fig. 1. HOE 2 : a Collaborative Top-Down Process for Embedded System Design

Fig. 3 .

 3 Fig.3. The HOE 2 Four Models

Fig. 4 .

 4 Fig. 4. Common HOE 2 model lifecyle Fig. 4 is a state machine that models the common lifecyle of all HOE 2 models. First, the model is INITIALIZED.In the INITIALIZED state, the model is built from upstream models. After initialization, a first modeling activity has to be performed. After the activity is performed, the model under development evolves into the MATURED state. This intermediate state means that the model is not fully complete, but it reaches a sufficient degree of ripeness to initialize the next phase. In the case of the implementation model, code generation can be performed from it. Finally, a model is marked as COMPLETE during the closing activity. This activity is performed by the project manager when he or she considers the model under development is complete. Except for the first one, each model may be considered as complete when each modeling activity performed on it contributes to satisfy all the requirements formalized in the upon requirement model.

Fig. 5 .

 5 Fig. 5. HOE 2 Activity Package & Modeling of the HOE 2 Requirement Activity Diagram

Fig. 6 .

 6 Fig. 6. Requirement tasks in the HOE 2 Activity Package

task 3 (

 3 Closing): Last task closes the phase by considering the model as complete. The output is a COMPLETE requirement model. It covers the formalization of the whole requirements.

1Listing 2 .

 2 self.system > 0 Listing 1. Precondition: the model is in INITIALIZED or MATURED State 1 self.actor->filter (a : Actor | a.causality = 'primary')-> size () > 0 self.system.usecase->filter (u : Usecase | u.causality = ' primary')->size () > 0 Postcondition: the model is in MATURED State

Fig. 8 .

 8 Fig. 8. HOE 2 Project Management Metamodel

Fig. 9 .

 9 Fig. 9. Consistent Planning of Developments: (a) regular organization and (b) organization enhancing prototyping

TABLE I

 I Face Tracker embedded system. It is embedded on a Pan & Tilt Camera platform which includes a number of processors, a Passive InfraRed (PIR) sensor and a bracket on which the camera is attached. Two servomotors are used to orientate the bracket in two axes.

		.	FACE TRACKER EMBEDDED SYSTEM USECASES
	Id	Name		Causality	Description
	1	Subscribe to in-	Primary	The actor subscribes to the system infor-
		formation flux		mation flux. The system is able to notify
					him of any presence or face detection.
	2	Switch to auto-	Secondary	The actor switches the system to automatic
		matic mode			mode.
	3	Switch to man-	Secondary	The actor switches the system to manual
		ual mode			mode.
	4	Orientate	the	Secondary	The actor manually orientates the camera
		camera
	development system with spread ones.
			presence detected / activate camera
			PRESENCE DETECTING		orientate bracket(α, β) face detected (x, y) / FACE TRACKING
		presence no longer detected /
		desactivate camera; orientate (αinit, βinit)

VI. A FACE TRACKER EMBEDDED SYSTEM CASE STUDY

In this section, we present a  Fig.

10

. Case Study: The Face Tracker Behavior

TABLE II .

 II FACE TRACKER EMBEDDED SYSTEM SCENARIOS

	Id	Name		CU	Nature	Description
	1-1	Presence	1	nominal	The actor subscribes to the system in-
		&	face			formation flux. Both presence and face
		detected			are detected. The system notifies the
		notification			presence and the position of the face.
	1-2	Presence	1	nominal	The actor subscribes to the system in-
		detected			formation flux. Only the presence is de-
		notification			tected. The system notifies the presence
						and the position of the face.
					. . .
	2-1	Automatic	2	nominal	The actor switches the system from man-
		mode				ual mode to automatic one.
		switching
	2-2	Automatic	2	error	The actor tries to switch to automatic
		mode				mode but the system is already in this
		switching			mode.
					. . .
	4-1	Camera	4	nominal	The system is in manual mode, so the
		orientation			author can orientate the camera.
	4-2	Camera	4	error	The system is in automatic mode, so the
		orientation			author cannot orientate the camera.

Acknowledgements: This work was partially funded by the EU Artemis JU and the French Ministère de l' Économie, du Redressement productif et du Numérique for COPCAMS under GA 332 913. Christian Fabre would like to thanks Bernard Rygaert for introducing him to requirements-driven iteration scheduling for MDE.