Calmet Michel
email: michel.calmet@gmail.com

Sallantin Jean
email: jean.sallantin@gmail.com

CD Lyons Keith

Evaluation or Analysis of a Live or a Recorded Video Sequence: An Example in the Analysis of Sports Videos

Keywords: live decision making, to intervene/to annotate, live actors, judo match analysis

Background. Since 2006, at the Faculty of Sport Sciences of Montpellier, to train students in the use of sportive video analysis with general and specific software, students must build 4 specific applications. These ICT skills are part of those defined by the Ministry of Higher Education, and the feature of these applications is the use of "delayed videos" analysis. Their learning journey is supported by on line tutorials. To consider the ever-increasing efficiency of new technologies and go further in video analysis, we have added a step (a fifth application): the use of "live videos" analysis excluding the backtracking of video. The benefits of this type of work can help decision-making in everyday life and therefore concern the world of sport. Problem. The purpose of this work was to observe students analyzing a recorded video sequence excluding video backtracking, as if they were live, as a coach. The feasibility conditions of such an experiment led us to study a judo combat by appreciating or estimating the interactions between different criteria as a coach. Method. After training, Masters students (n=12), who specialized in the video analysis and in judo performance, analyzed (they studied three times the same combat) the balance of power (subjective criterion) between two judokas. The process required the student observers to identify whether a judoka was "dominant, i.e.: in a favorable organization to win" or "dominated" whilst managing his/her actions in "programmed/conscious" or "automatic, i.e.: reflex organization" modes. Nonparametric Kolmogorov Smirnov and Wilcoxon tests were used to analyze the data collected by the students. Conclusions. These tests indicated that the analyses were identical and stable at the intraobserver (p=[0.095: 0.999], p=[0.219: 1.0]) and group levels (p=0.224; p=0.406). We propose to include this methodology of analyze in Masters' students training programs and develop these live analyses for coachs, teachers or referees.

Introduction

The first analyses of sports sequences date back to the end of the 19 th century. Scientist pioneers were Muybrige, Demeny and Marey, [START_REF] Mannoni | Georges Demenÿ, pionnier du cinéma[END_REF][START_REF] Frizot | Etienne-Jules Marey: Chronophotographe[END_REF][START_REF] Adam | Eadweard Muybridge: The Complete Locomotion Photographs[END_REF]. Their works allowed qualitative analyzes (interpretation of the action) and quantitative analyses (distances, velocities, time, power). Research has been carried out on analyses of video sequences of people at work, in everyday life, and in the field of sports activities. The person is filmed inside a context and the research focuses on the meaning of the person's actions in this context [START_REF] Knoblauch | Video-analysis methodology and methods[END_REF]]. In sports activities, analysis of video sequences is important to train students, and support coaches and athletes. Many proprietary tools are available for use on a variety of computing platforms. Protected by copyright and are purchased with a license agreement, these tools allow analyze performance in three modalities: in delayed time; in real time with a delay; and in real time with no delay. Since 2006, Masters students, in the Faculty of Sport Sciences of Montpellier, are trained to ICT, in accordance with the instructions of ministerial National of Education [START_REF] Technologie | NOUVELLES TECHNOLOGIES, Certificat informatique et internet (C2i) ®[END_REF][START_REF] Technologie | Généralisation du C2i® niveau 2 métiers de l'ingénieur[END_REF][START_REF] Men | Suggestions for Judo Training with Pacing Strategy and Decision Making by Judo Championship Phases[END_REF], and to sportive video analysis. To learn ICT and concepts, students build four free applications (video analysis; multicriteria analysis; chart video-coupling; decision support system) that use objective criteria (first three applications) or subjective criteria (last one). Their learning journey is supported by on line tutorials. By building their applications and analyzing videos, students acquire the competences defined in these ministerial instructions. These four applications are adapted to students' level of computer knowledge. They fall under the generic type of video analysis software [START_REF] Bloomfield | The 'Bloomfield Movement Classification': Motion Analysis of Individual Players in Dynamic Movement Sports[END_REF]. The feature of these applications is the use of "delayed videos" analysis, but investigations results concerning the "satisfaction of this course", showed students' great appreciations with these applications [START_REF] Calmet | Survey of the Evolution of Two Points Belonging to Two Objects Falling withoutInitial Speed Dynamic, Chart (Dot per Dot) Video (Frame by Frame) Coupling[END_REF]. Working on debate analysis requiring to consider several criteria [START_REF] Luzeaux | Extensions of Aristotle's square[END_REF], considering the ever-increasing efficiency of new technologies and to go further in sportive video analysis, we have added a step within a fifth application: the use of "live videos" analysis with several criteria, excluding the backtracking of video.

Aim of the study

Starting the process of such an experiment appeared difficult, but it seemed possible to move from : "analyzing a debate" [START_REF] Knoblauch | Video-analysis methodology and methods[END_REF] to "analyzing a combat". In these two situations (debate and combat) till the time out, each of the opponents will try to dominate the other to show that his point of view is the best or to win the match. In these two situations, interactions are permanent and high-intensity phases follow less intensity phases. This led us to study a judo combat by appreciating or estimating the interactions between different criteria as a coach does it, in live in the field. It was about analyzing sportive strategies and tactics [START_REF] Dufour | Football, l'observation traitée par ordinateur[END_REF], not concerning the management of a sportive event [START_REF] Liu | Deep learning based basketball video analysis for intelligent arena application[END_REF] and not only collecting the displacements coordinates (x and y) according to the time [START_REF] Adami | Vers une approche nouvelle du judo de haut-niveau[END_REF]. Examples of important interactions in a judo combat:

• attack and defend at the same time • act to create uncertainty in the opponent (suggest that we will attack in a direction, to attack in another direction) • manage the uncertainties created by the opponent • reflex counter attack (training allows to develop this type of skills) [START_REF] Potdevin | Les différents types de mouvement[END_REF] • manage the score Topics of research on the analysis of judo combats with "delayed videos" generally relate to technics or penalties (frequency, genre, weight categories, biomechanics, winner and nonwinners):

"The techniques used by judoists during the world and Olympic tournaments 1995-1999" [START_REF] Sterkowicz | Techniques used by judoists during the world and Olympic tournaments 1995-1999[END_REF], "A new classification proposal of Judo throwing techniques" [START_REF] Almansba | A new classification proposal of Judo throwing techniques: a pilot study[END_REF], "Techniques frequently used during London Olympic judo tournaments: A biomechanical approach" [START_REF] Sterkowicz | Techniques frequently used during London Olympic judo tournaments: A biomechanical approach[END_REF], "Three-dimensional assessment of the judo throwing techniques frequently used in competition", [START_REF] Santos | Three-dimensional assessment of the judo throwing techniques frequently used in competition[END_REF], "Validation of a video analysis software package for quantifying movement velocity in resistance exercises, [Sanudo et al, 2016], "Home advantage in judo: analysis by the combat phase, penalties and the type of attack", [START_REF] Brito | Home Advantage in Judo: Analysis by the Combat Phase, Penalties and the Type of Attack[END_REF], "Techniques utilized at 2017 Judo World Championship and their classification" [START_REF] Martins | Techniques utilised at 2017 Judo World Championship and their classification: comparisons between sexes, weight categories, winners and non-winners[END_REF]; "Suggestions for judo training with pacing strategy and decision making by judo championship phases" [Miarka et al. 2018], "Video analysis of judo situations to learn physics" [START_REF] Michelini | Video analysis of judo situations to learn physics[END_REF].

There is little research on the analysis of judo combats with "live videos", their features relate decision-making for coaches or athletes: "Is visual search strategy different between level of judo coach when acquiring visual information from the preparation phase of judo contests?". In this paper, Participants were instructed to provide verbal coaching instructions to improve a specified judoka's performance at set times during the footage [START_REF] Robertson | Is visual search strategy different between level of judo coach when acquiring visual information from the preparation phase of judo contests ?[END_REF]. A similar survey with athletes was conducted about fencing, recording gaze direction with NAC eye mark recorder [START_REF] Papin | L'éducation des stratégies de prise d'informations visuelles[END_REF]].

The aim of this work was to observe students analyzing a recorded video of a judo combat, without backtracking [START_REF] Knoblauch | Video-analysis methodology and methods[END_REF]], as if they were live, as a coach. This analysis consisted of appreciating or estimating the interactions of the two judokas according to two criteria: 1) "dominant, i.e.: in a favorable organization to win" vs "dominated" and 2) "programmed/conscious" vs "automatic, i.e.: reflex organization" [START_REF] Potdevin | Les différents types de mouvement[END_REF]. The appreciation or estimation of the interactions, specific to each user, is "subjective".

Methods

This work

is not yet under study with statistical groups, it is a working track to conduct more precise research [START_REF] Cariou | Stimuler la moelle épinière, ça marche ![END_REF]. Twelve students (n=12), in their third year of study in the Faculty of Sport Sciences participated voluntarily in this research project. They were aged 20.6 ± 2.2 years, all judo specialists (brown belt to black belt (1 st to 2 nd Dan), practicing from 4h to 12h of judo per week), and having attended judo specialty courses and an ICT course for three years at university. These 12 students worked previously with video analysis applications under MS-Excel to define the system of attacks of judokas [START_REF] Calmet | Survey of the advantages obtained by judoka in competition according to their level of practice[END_REF][START_REF] Calmet | Survey of the system of attacks of regionalinterregional level's judoka[END_REF]]. After training, they used the application to analyze the balance of power between two judo players. To analyze the same recorded video sequence, they must click with the mouse to specify an observation or annotation when playing the video. This experience would allow:

• To learn how manage a compromise between different criteria, as often in a professional situation. • To draw a map of students' annotations (scatter plots of the clicked points) to display their decisions graphically and compare the homogeneity and repeatability of their analyses. • To improve students' competences in two disciplines: video analysis (working with different criteria) and ICT (how are working professional softwares). The frequency for annotations was based on the duration of a combat sequence (20 s) [START_REF] Castanerlas | Estudio de la estructura temporal del combate de judo[END_REF]Franchini, Artioli, Brito 2013] and/or the duration assigned to the referee to give a non-combativity penalty (about 30 s) [START_REF] Ijf | IJF Referring rules[END_REF]]. For a 5min long combat, the order of magnitude of the annotation number for a student was 10 annotations (2 per min) to 15 annotations (3 per min). The students were aware of these temporal phases (20 s to 30 s), and they had only the stopwatch of the combat clock (embedded in the video) as reference. The "dominant" vs "dominated" (y axis) was well understood by the students. The "programmed/conscious" vs "automatic" (x axis) gave rise to some exchanges about their own practices as judoka or referee. They better understood this x axis when: "automatic" could be related to rebalances, changes in support or reflex counter-attacks; and "programmed 1 /conscious" [START_REF] Chambily | WCs in Budapest: «Teddy est très prudent[END_REF]]could be connected to a voluntary attack trigger or positioning on the mat: near the combat limit, keep the opponent in a corner of the mat [START_REF] Potdevin | Les différents types de mouvement[END_REF].

A demonstration of the use of the application with a combat was made to the 12 students for 5min. Then students learned to use the application with this combat for 10min. This combat was 2min long, to allow students to have 4 trials [START_REF] Hopkins | Spreadsheets for Analysis of Validity and Reliability[END_REF]].

4 Tools MS-Excel allows the creation of applications adapted to the users' needs, and in that case, facilitates the sharing of concepts involved in video analysis. A fifth application was built permitting on one hand, the analyze of a recorded video sequence excluding video backtracking and on another hand the appreciation or estimation or the interactions between two criteria. When the user clicks, his action is recorded. Each student's click corresponds to an observation or annotation. The example shared below, show the work of a student to assess the balance of power between two judo opponents. While observing the real-time video of a judo combat, student coded (clicked) in the "area to collect data" whenever and how he thought that the winner was acting in a "dominant" or "dominated" mode (y axis) whilst managing his/her actions in "programmed/conscious" or "automatic" mode (x axis) [START_REF] Potdevin | Les différents types de mouvement[END_REF]. The two axes delimited 4 sectors to collect observations or annotations. Each click in the "area to collect data" was recorded, a dot appeared immediately in the chart, and the dot was erased in the "area to collect data" (Figure 1). To test the functionalities of this fifth application became a sub-goal.

Data collection and statistical analysis

Students worked for 20 min on the analysis of the same combat (a second round from the 2014 world championships between Iliadis and Rodriguez, in the 90kg weight category). This combat was chosen specifically because the initial time was 5min, the winner was often dominant, made few attacks, scored twice and scored the decisive point (ippon) just after 3min of combat. Students had to view this judo combat 3 times and click in the area to collect data (Figure 1) containing the two axes to indicate how was acting the winner. Each student's annotation (i.e., each dot) was referred to the x and y coordinates. Data were analyzed using the XLSTATS 19.03.45137 pack2 . Nonparametric Kolmogorov-Smirnov and Wilcoxon tests were used to analyze data. A significance level was set at 5%.

Results

The application was useful and data collected allowed the analysis of performance.

Study of the number of annotations recorded during the analyses

The analysis of the 3 viewing of the combat indicate that the first analysis included for 5 students very different number of annotations (-12 to +4) between the first analysis and the other two. In addition, one student made 53 and 26 annotations for analyzes 2 and 3 respectively. Our results therefore relate to the 2 nd and 3 rd analysis of 11 students (Table 1). Two groups (Figure 2) appear with mean ± SD (A: 8.6 ± 0.8: B: 15.6 ± 2.9). Furthermore, students did more annotations than expected: for a 3min long combat, we could expect 6 to 9 annotations, and students' annotations (mean ± SD) were 11.7 ± 4 and 12 ± 4.3.

As the two numbers of annotation for analyses 2 and 3 were comparable, it was possible to study the distribution of the coordinates of these annotations.

Survey of the distribution of the coordinates of the 261 annotations

The total of the annotations was 261 (129 + 132, for analysis 2 and 3, respectively): -100% of the coordinates of the annotations were in the same area (green) of coordinates (Xmin=4, Ymin=10, XMax=309 and YMax=494), i.e. 12.3% of the total area to collect data.

-83% of the coordinates of the annotations (108 for X2-Y2 and 108 for X3-Y3) were in the same area (yellow) of coordinates (Xmin=4, Ymin=205, XMax=196 and YMax=494), i.e. 4.6% of the total area to collect data (Figure 3). Figure 3 shows a high concentration of clicks in the same area for analyses 2 and 3. Students seem to have repeated the same analysis on their 2 nd and 3 rd tests.

Survey of the repeatability of the analyses

The measurement method, used by the same operators, with measurement conditions that have remained identical (the time interval between the 2 nd and 3 rd analysis is negligible) seems reproductible or repeatable [START_REF] Desquilbet | Répétabilité, reproductibilité, et concordance de méthodes de mesure, V9[END_REF]]. X values and Y values concerning 11 students (i.e. where they clicked in the area to collect data cf. Figure 1) can be compared.

DOMINANT PROGRAMMED AUTOMATIC

DOMINATED

Using Kolmogorov-Smirnov nonparametric test, bilateral test, the samples X2, X3, Y2, Y3 do not follow a normal distribution, respectively: p=0.004; p=0.002; p=0.047, p=0.018.

Distribution as histograms of the coordinates of the 261 annotations

A way to display students' annotations and repeatability, is to count how often values occur within a range of intervals. As X2, X3, Y2, Y3 do not follow a normal distribution, we used Yule's rule. It is a Sturges rules alternative [START_REF] Sturges | The Choice of a Class Interval[END_REF]] to calculate the number of intervals (k=2.5 × √𝑑𝑎𝑡𝑎 4 ): k is the number of intervals and here, data is the average of annotations (129+132)/2=130.5. In that case k=8.44 means 8 intervals. The low accuracy of the mouse and the absence of audio-time references allow us to better understand the differences between the values of the coordinates. The most important difference for clicks in Figure 8 is "Objet1": 79-40=39, or 39/1000 (1000 is the length of x axis), i.e. 3.9% of the X axis in Figure 1. Stud-10's coordinates X2/X3 follow the same distribution (Figure 9), the Kolmogorov-Smirnov nonparametric test resulted in p=0.916, and Stud-10's samples X2/X3 are comparable, the Wilcoxon nonparametric test resulted in p=0.953. In Stud-10's example, only the X values have been processed, for all the comparisons, both for the group and for each student the X2/X3 coordinates and the Y2/Y3 coordinates will be analyzed in the same way as Figure 9.

Distribution with cumulated frequency of the coordinates of the 261 annotations

The X2/X3 samples and the Y2/Y3 samples follow the same distribution, the Kolmogorov-Smirnov nonparametric test resulted in p = 0.951 (Figure 10) and p = 0.533 (Figure 11), respectively. -The X2/X3 coordinates distributions and Y2/Y3 coordinates distributions were comparable. -The X2/X3 samples and the Y2/Y3 samples of these students were comparable. Students have had homogeneous analysis level, as shown by the similarity of analyzes 2 and 3 concerning the same combat (Figure 3, Figure 4, Figure 5, Figure 10, Figure 11). Green square in Figure 3 is a kind of static map, the locations of the coordinates Figure 6 and Figure 7, are a kind of dynamic map, the shifts of the 11 mice to click. The chosen combat was a good example for a first step. Students well considered that the winner was acting as Programmed-Dominant:

-As dominant he imposed his actions -As programmed he imposed his intentions of actions. However, the high concentration (geographically) of the coordinates shows that students understood the work to be done and differentiated the two axes of analysis (Programmed/Conscious vs Automatic and Dominant vs Dominated). Their great interest and concentration (intellectually) during this work could come from: their knowledges/skills, the application and an innovative analysis with the 2 proposed axes. This example of innovative work leads them to interrogate both their knowledge in judo and their use (and build) of different tools. Our future work in this area will:

-Continue this way of analysis with combat involving one or more status reversals ("judoka 1" dominating for 1/3 of the time, then "judoka 1" dominated for 1/3 of time, then "judoka 1" winner by decisive point in the last part of the combat). -Organize an analyze with two students (one student analyzing a judoka and the second student analyzing the second judoka) to study how the two analyzes are complementary. -Introduce a hidden time frame to the users to locate their annotations from a qualitative point of view. This time frame could contain annotations from experts. -Simplify the MS-Excel application to make students more autonomous in their constructions and advanced uses of office tools. -To verify the contribution of this type of tools in the formation for the "live actors". The use of "live videos" to analyze behaviors or train users of system of video analysis seems in development, data mining and artificial intelligence are giving us new possibilities to explore. "Visual Video Analytics for Interactive Video Content Analysis" could be an example of reflection [Schöning and Heideman , 2018], in this experiment, the user (the analyst), helps the computer in close cooperation to translate the pixels of videos to meaningful content.

Disclosure statement

The declare that there is no conflict of interest.

Figure 1 .

 1 Figure 1. Screenshot of the application to collect data (notational analysis) during the analysis of the combat. Video showing how the application works (hit escape to access the video)

  Figure 2.: distribution of the numbers of annotations

Figure 3 .

 3 Figure 3. coordinates of the annotations (clicked points)

Figure 4 .

 4 Figure 4. distribution of X2 and X3 for 11 students with 8 intervals Figure 5. distributions of Y2 and Y3 for 11 students with 8 intervals

Figure 6 .Figure 8 .Figure 9 .

 689 Figure 6. coordinates of X2 and X3 as curves for 11 students Figure 7. coordinates of Y2 and Y3 as curves for 11 students Fig 6 and Fig 7 represent the variations of the clicks for 11 students concerning the x-axis (fig 6) and the y-axis (Fig 7).

Figure 10 .

 10 Figure 10. distribution of X2/X3 coordinates for 11 students Figure 11. distribution of Y2/Y3 coordinates for 11 students

Table 1 .

 1 Number of annotations concerning analysis 2 and analysis 3 for 11 students

		NB	NB
	Students	annotations	annotations
		analysis 2	analysis 3
	Stud-01	10	9
	Stud-02	9	9
	Stud-03	15	17
	Stud-04	18	18
	Stud-05	15	19
	Stud-06	9	8
	Stud-07	10	13
	Stud-08	18	13
	Stud-09	8	8
	Stud-10	9	10
	Stud-11	8	8
	Average	11.7	12
	Stand. Dev.

Addinsoft (2019). XLSTAT statistical and data analysis solution. Long Island, NY, USA. https://www.xlstat.com

Acknowledgements

Bernard Royer for his help and advices about analysis. Special thanks to students: Dylan Leeuwerck, Marion Sarroca, Cédric Jaszczyszyn, Doudon Romain, Delonca Jean, Landes Alexandre, Lecarderonnel Julien, Mellado Julien, Roy Raphaelle, Rychter Alan, Rychter Mael, Tschumi Omegane.

Survey of the distribution of the annotation coordinates for each student

Conclusions

This application seems functional and easy to use. As in our previous studies on institutional surveys of course satisfaction, students said they liked this kind of work and had a better understanding of how professional software works. In MS-Excel, a userform is necessary to collect the data and VBA commands are of the same level than the four applications. We can consider a new tutorial to help students to build this fifth application. For students, the PROGRAMMED/Conscious vs AUTOMATIC axis was difficult to perceive at the beginning of the study, contrary to the DOMINANT vs DOMINATED axis. Eventually, they did understand the work to be done even if the first analysis should have been considered to learn the application. We will increase learning time in our upcoming courses. The repeatability concerning students' analysis is strong, although they worked without visual/audio/time reference. For the 11 students, the X2/X3 and Y2/Y3 coordinates distributions were comparable and the X2/X3 and Y2/Y3 samples were comparable. We can underline the quality of homogeneity of their results without audio signal or metronome to click quite in the same way. There was no significant difference between the numbers of annotations (Table 1), but we can differentiate 2 groups who clicked (A less and B more) but in the same way and with the same number of annotations for each group during the 2 analyses (Table 1 and Figure 2). The analysis (Table 2) shows for 82% of students:


Luisa Rincón

Edwin Muñoz

Juan-C Martinez

Maria-C Pabón

Gloria Álvarez

Extractive SPL Adoption Applied Into a Small Software Company

Keywords: Software Product Lines, Domain Engineering, Feature Models, Core Assets, Industrial Case, Reusable artifacts, Extractive adoption

Acople Tecnológico SAS is a Colombian enterprise specializing in software development whose products use devices for biometric facial and fingerprint recognition. The functional overlap of such products provides an opportunity for systematic reuse, which reduces software development and maintenance costs. In this paper we report our experiences, lessons learned and future work from applying concepts of software product line engineering to evolve three of its different software applications into a software product line. Based on our experience, we explain how we have tailored existing concepts of product line engineering, specifically how we have followed the process thus far, which includes the variability analysis that refers to the study of commonalities and variabilities among a set of software applications, the development of reusable software assets, and the derivation of individual products from the product line.

I. INTRODUCTION

Software Product Line Engineering (SPLE) is a software development paradigm that seeks to create product families rather than creating individual products. These families group a set of products that share common characteristics while having some variations from each other. The software product lines (SPL) allow to capitalize on the development effort in many products while efficiently managing their differences. The SPL promise benefits such as reuse and reduction in development time and costs [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF].

The domain engineering and the application engineering are the two main process of the SPLE [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF]. Domain engineering consists of studying the commonalities and variabilities among a set of software applications and developing the reusable artifacts and resources that form the basis for the software product line (core assets) 1 . These core assets will enable the rapid construction of particular software system belonging to the same family of products. Application engineering, in turn, consists of analyzing, designing, building, customizing, and testing the final products, using the core assets and the specific requirements expressed by the customers. The domain engineering process is executed once in order to construct the 1 http://www.sei.cmu.edu/productlines/start/glossary/index.cfm product-line infrastructure, whereas the application engineering phase is executed each time a new product is derived from the product line.

SPLE has been applied in several domains, especially in large-scale software development [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF]- [START_REF] Parra | An soa approach for automating software product line adoption[END_REF], but it also has increasingly garnered interest from small to medium-sized companies. Motivated by those experiences our general goal is to apply the related concepts of software product line engineering to Acople Tecnológico SAS, a small Colombian enterprise specializing in software development.

In this paper, we propose a step to achieve this goal. Specifically, we present how we have followed the process thus far, which includes the variability analysis that refers to the study of commonalities and variabilities among a set of software applications, the development of reusable software assets and the derivation of individual products from the product line. We have followed an extractive adoption strategy [START_REF] Krueger | Easing the Transition to Software Mass Customization[END_REF], because it allows us to develop the new assets while taking advantage of the software artifacts already developed by Acople Tecnológico. In fact, we used as reference three applications that Acople Tecnológico had previously launched on the market.

We believe the use of a SPLE approach in Acople Tecnológico can be significantly advantageous because this company has a portfolio of software products that share a significant amount of functionality and code, but are developed, tested and maintained separately. This has led to high costs in terms of time and technical resources which wasted technical resources and involved a high investment in time and cost.

The remaining parts of this paper are structured as follows. Section II, gives an overview of the characteristics of the company and its context (domain analysis) and presents the model as a result of analyzing company's applications. Section III explains how we defined the reusable modules that implement the features defined in the variability model that we proposed as a result of analyzing the company. Section IV, presents the benefits and lessons learned in the use of a SPLE approach. Section V, provides a summary of works related to our proposal, and finally Section VI presents the conclusions and suggests future research directions.

II. VARIABILITY ANALYSIS

A. Domain Analysis

Acople Tecnológico SAS is a small software company located in Cali, Colombia. It has over six years of experience and since its establishment, it has been delivering software solutions at the enterprise level using biometric devices. Over the years, Acople Tecnológico SAS has developed and marketed several independent applications. In fact, well-known Colombian enterprises such as Proservis Temporales SAS, Coca Cola Cali, or Servientrega SA, have successfully used Acople Tecnológico's applications.

Based on the company's experience, we have chosen three applications developed by Acople Tecnológico that share many different features as a base to carry out an analysis of their variability to define the variability inherent to the product line.

Chosen applications were: Working Time Control, Access Control, and Restaurant. A brief explanation of each one is presented below:

• Working Time Control: this application measures how much time each employee works during his working day. Its main purpose is to identify the start and the end of the working days to prevent fraud and irregularities when working time of each employee is calculated.

• Access Control: it manages permissions to control access to highly secure areas. To achieve this, the application identify who each person is by means of biometric devices.

• Restaurant: this application uses biometric identification to control the schedule to deliver food and to authorize people for receiving lunches or dinners when they are sponsored by an enterprise.

Several analysis techniques can be used to analyze and model the variability. In our case, we used feature modeling as the notation to represent our product line, because this notation has been widely adopted in the Software Product Lines community [START_REF] Berger | What is a Feature?: A Qualitative Study of Features in Industrial Software Product Lines[END_REF]. Under this notation, each feature is a node in a tree structure and represents a distinguishable characteristic that is relevant to our stakeholders, from a technical or functional point of view. The tree's root of the Feature Model represents whole product line, and it is decomposed into its most prominent features. Then, these prominent features are decomposed into their prominent sub-features, and so on, until the family is entirely decomposed into features.

Among features there are several relationships to define how features are related each other, depending on, for instance, if a child is an optional or a mandatory feature. Specifically, there are three types of relations: mandatory, optional and group cardinality. Mandatory features (dark circles) are always selected, optional features (white circles), can be chosen or not, and cardinality group features (arc with UML cardinality), where the selection is realized among a limited set of alternatives according to the cardinality. In addition, the notation introduces two types of constraints among features: requires and excludes. The requires constraint states that for a given feature to be selected, the required feature has to be selected too. The excludes constraint states that for a given feature to be selected, the excluded feature has to be deselected [START_REF] Czarnecki | Formalizing cardinalitybased feature models and their specialization[END_REF].

Given the complexity of each application, we modeled the variability of each application through individual feature models first. Doing so, we identified features shared by the three applications such as Reports, People, Notification or Device. Furthermore, we identify features such as Calendar or Schedule that were considered only by one of the applications, but could be optionally used in other applications to extend their functionality. Moreover, we detected some features that were managed as separate concepts, but could be generalized into more general terms in order to unify them as one. For instance, we created the feature Application Type to generalize the three types of applications that were factored to extract the product line, and we decomposed this feature into three subfeatures: Working Time, Restaurant and Access.

B. Resulting Feature Model

Figure 1 shows the feature model we constructed as a result of analyzing each application separately. Below, we briefly outline the functionality of each feature.

• Application Type refers to the main functionality of a product. Currently, it includes Working Time, Access, and Restaurant types. There is a mandatory relation between the features Working Time and Schedule. In fact, a product that includes Working Time should also include Schedule, to manage staff shifts.

• People is related, on the one hand, with the management of the people that could be identified by the biometric devices (Person Identification) and, on the other hand, with the management of the administrative users (Application Users). Any product of this product line should always identify, by means of biometric devices, people who belong to the organization (Insiders), and it may optionally identify people not belonging to the organization (Outsiders).The application administrative users could generate Reports.

• Records represents the mechanism used to transfer the information captured by the biometric devices to the application. This communication could be Online when the device has Internet access or Batch when records should be manually downloaded to the system. It is noteworthy that if the Application Type is Access, then it is essential to have Internet access, and thus there is an exclusion relation between the features Access and Batch.

• Device refers to different kind of biometric devices that could be used by an application. Currently, the SPL considers two kinds of devices, Facial and Fingerprint, however, the SPL could be extended to incorporate iris, voice, or card recognition.

• Number of People represents the maximum number of people that the biometric device could identify. This feature has two sub-features P 0 to 1200, which means from zero up to one thousand two hundred people is supported by the device, and P 1200 to infinite, which means the device supports over one thousand two hundred people. Currently, the facial • Transaction points out how a new event is registered.

An automatic transaction takes the data directly from the biometric device. Otherwise, the data comes from a manual process. Any product derived from the SPL would have defined one transaction type. Optionally, a biometric application can manually register data. Otherwise, data should be captured by biometric devices.

• Measure Unit indicates what is measured, calculated, or controlled by the application. For example, the feature Consumption has to be used for product or service management, or to control the consumption. Activity has to be used in transactional applications, for example, to manage the purchasing of goods and services. Time has a variety of uses, such as, working or delivery time calculation. Depending on what type of application is selected it is necessary to select a different Measure Unit. We use among those features some requires relations, as can be seen in the Figure 1, to control this dependency.

• Notification is about notifying application users and stakeholders of particular system conditions or events.

• Calendar includes the organization and management of calendar, including holidays. According to our domain analysis, applications that contain the feature Access must also include the Calendar feature.

The feature model is the result of an iterative design process with the participation of a functional and technical expert from Acople Tecnológico. This expert, who has many years of experience, validated the resulting model assuring that we had correctly modeled the business domain concepts. Moreover, we verified the model by using VariaMos2 , a modeling tool that offers automatic verification of feature models. It helped us to be sure that our model is correct since it is free of errors. Additionally, by using Variamos, we found the number of different products that could be obtained from our feature model. Variamos determines the number of products based on the combinations resulting from adding and subtracting features. The analysis of the proposed feature model established that 320 different products could be generated. Taking into account that the model includes the features found in three previously developed products, the possibility to obtain 320 products shows that software product lines facilitate reuse planning.

According to Acople Tecnológico's experience, of these 320 potential applications, the feature Application Type determines the main commercial products and therefore six of them, resulting from combining this feature and its sub features, are very attractive from a commercial point of view, even though other possible combinations could be commercialized too. Based on this idea, Acople Tecnológico plans to define a classification of products according to the Application Type to manage a licensing schema. This schema could include several versions, like Basic, Business, and Corporate licenses. The license would be defined along with the product characteristics and functionality. For example, a Working Time control product could be a Basic application whereas a Working time + Access + Restaurant product could has a Corporate license.

Once we analyzed the common and variable elements in our domain, the next step was to design a flexible software architecture that supports the specified variations. The next section explains how this goal has been achieved in our particular case.

III. DEVELOPMENT OF REUSABLE ASSETS

At the current level of the proposed product line, we have defined software modules as core assets of our product line, but we have not yet defined other assets such as unitary test cases, process descriptions, or any other element of a software production process. In this section, we explain how we have defined reusable modules that implement the features defined in our variability model, and how we used those modules when we want to assemble products from the product line.

A. Core Assets Definition

According to Bachmann and Bass [START_REF] Bachmann | Managing variability in software architectures[END_REF], there are two possible techniques to implement a variation on core assets: module replacement and data controlled variation. By using the first technique, multiple code-based versions of a particular module are implemented and later, at the execution time or at an earlier stage, the correct one is chosen. In the second technique, the variability is internally implemented inside of a single module, hiding the adaptation on the architecture level.

Given that Acople Tecnológico was just becoming with the product line approach, we considered more suitable to group features with close functionality in modules and to implement the variability inside the module when necessary. In total, we defined nine modules: People, Devices, Schedule, Calendar, Records, Application Type, Reports, Notifications, and Common. Calendar, Schedule and Notifications are modules with an optional scope [START_REF] Kim | A theoretical foundation of variability in component-based development[END_REF], which means they may or may not be included in the applications obtained from the product line. Modules Devices and Application Type have an open scope [START_REF] Kim | A theoretical foundation of variability in component-based development[END_REF], which means they have already known variants, but a set of possible values can still be extended later at the time, for instance by adding a new type of application. Modules People and Records have a binary scope because they have two possible variants which are already known [START_REF] Kim | A theoretical foundation of variability in component-based development[END_REF], and the rest of the modules are reusable software components that implement the product line commonality, but they do not support variability. At an internal level, we use a table to keep the traceability between each module and the features that it implements. Next, we explain the main aim of each module.

The People module manages operations related to the features People and Application Users. Some of those operations are to manage user accounts, permissions, log-offs, password changes, and more. On the other hand, the functionality of the Person Identification feature is controlled by recording each person directly on the biometric device.

The Device module controls the communication between the software application and the biometric devices by means of operations for downloading records, controlling the number of users, and adding new biometric devices. This module supports the feature Device. In addition, this module also supports the features, Number of People, P 0 to 1200 and P 1200 to infinite which are useful to define how many people will be supported by the software application.

The Schedule module is in charge of managing aspects related to staff scheduling and the Calendar module manages information about holidays required by the applications. The Records module handles the registry of data delivered by the biometric devices as well as data required by each application type. This module also enables the addition of attributes to the Records table according to the particular requirements of each application. The attributes are added trough SQL statements, like ALTER TABLE, and the portions of code that manipulate the database information manage those schema differences, making them transparent to the final user. This module implements the features Records and Transactions, and their sub-features.

The module Application Type supports the three types considered in the SPL and the measure units associated with each type. The implementation of this module consists of two parts: an interface that exposes services shared by all the application types, and a particular java class for each application type that includes its own functions exposed as services. The Notifications module has the functionality for composing and sending messages and supports the feature Notification. Finally, the Common module supports functions shared among all the modules such as exceptions and dates handling, validations, currency format, and internationalization.

B. Core Assets Design and Implementation

We decided to develop assets by using Java EE technologies with the aim to quickly change Acople Tecnologico's conventional software development into a software product line engineering approach. We decided to develop assets by using Java EE technologies since previous assets were developed on Java EE technologies too, and therefore we can reuse, as much as possible, previous assets. To make this possible in an ordered way, each module presented in the Section III-A was implemented as a distinct (physically separated) code unit. This strategy, called compositional approach [START_REF] Kastner | Visualizing software product line variabilities in source code[END_REF], provides us a direct link between each feature and its implementation, giving us a high degree of feature traceability and therefore easier maintenance over time [START_REF] Zhang | Variability Mechanisms and Lessons Learned in Practice[END_REF].

We used feature model as a tool for modeling the domain of interest, but from a detailed design point of view, we used UML for describing, at the design level, the specific details of each module. As each module was considered as an independent part of code, we followed the Model View Controller pattern to design and implement each one of them. We chose this architecture because it gives us independence between the user interface of each module and its business logic. For instance, Figure 2 shows the design that we have made for the devices module. At the right side of the figure, into the devices model package, we put the business entities and we marked with blue color the ones that are not defined by this module, but that are required by it. Into the DevicesBusinessController package, we define the main business concepts. By using welldefined interfaces with clearly exposed properties and events, as presented by Gacek [START_REF] Gacek | Implementing product line variabilities[END_REF], we support variability for two different type of devices: fingerprint and facial recognition. However, the SPL is open to adding new types of devices in the future, as long as they follow the defined interface. Finally, on the right side, we present the graphic user interfaces (views) required to provide the full functionality of this module.

Model and controller layers were implemented as a Java SE project, which were packaged as a jar files, whereas the view layer was separated into two different parts, a view controller (managed bean) and a folder with .xhtml files that represents the module screens. As a result we had for each module three assets: a .jar file, a folder with .xhtml files and a .class file.

Model layer was implemented using the Data Access Object Pattern (DAO), to separate low-level data accessing operations from high-level business services. Common to all modules we defined and implemented a generic interface IDAO<T> where we declare standard database operations. Then, we defined the model entities that each module needed and we implemented a specific DAO for each entity. We reuse the most of the model entities previously developed by For the controller layer, we defined a public java interface with the available services of each module and at least one Java class for implementing those services. Outside of those modules only the public operations were accessible, obtaining as a result high cohesion and low coupling among modules.

Finally, the view layer was implemented with the Java Server Faces -JSF-technology. This framework provides the file faces-config.xml which is useful to define the managed bean associated to each view and the navigation rules among the different views of each module. For instance, according to the business logic in the module Devices it is possible to gain access to the view createDevice.xhtml only from the view listDevices.xhtml. For each module we defined those rules to incorporate them into a general faces-config file when a new application is derived. We also created a general template file template.xhtml which defines the appearance and distribution (header, content and footer) for all the final user screens.

C. Generate product line members

Currently, feature selection and product derivation are both manual activities. This means that although many parts of the implementation have been prepared during the domain implementation and can be reused, some activities are done manually. For instance, it should be defined what features will be selected from the feature model. Also, it has to be solved the relation between modules and features to determine which modules will be used according to the features selection, and each product has to be manually assembled based on the reusable artifacts. Later, the resulting product is verified before being delivered to a customer by functional test cases. We plan in the future to elaborate automated unit tests to automatize this part.

We based the derivation of new members of the product line on the "Configuration" [START_REF] Deelstra | Product derivation in software product families: a case study[END_REF] approach. In this approach, the first version of the product is based on a consistent set of modules that can function together. In this sense, to facilitate the derivation we created a base for any new application by creating a new web project in Eclipse JEE IDE 3 . This project In an effort to take advantage of the Acople Tecnológico's experience all applications obtained from the product line will follow the rules defined by the Java Servlet Specification, and the general architecture presented in Figure 3. The product line architecture is a layered architecture based on the client -server paradigm. Business, Data and presentation layers are separated into different source files. Specifically, the configuration and derivation tasks that have to be done manually to complete the product are the following:

1) Create a new database in the database engine installed on the application server. 2) Select from the feature model those choices that define client requirements and satisfy the model restrictions. 3) Identify the modules that have to be included according to the features previously selected, or configure modules previously included if they implement fullmandatory features. 4) Execute the SQL statements of each selected module to create tables and populate them with their basic data when required. 5) Move into the LIB folder the .jar files of each module previously identified and other third-party libraries required by the application. 6) Implement the requirements that could not be satisfied through the reuse of modules previously developed and adapt artifacts such as screens, style-sheets and figures to satisfy the customer requirements. 7) Copy into the sub folder classes, located in the WEB-INF folder, files with .class extension. These files are the view controllers which implement the logic associated to the views of each selected module. 8) Modify into the folder classes the file datasource.properties to adjust the database name for the new application. 9) Create in the xhtml folder a sub folder for each selected module and copy there the corresponding .xhtml files. Other screens that do not allow to any specific module, but are required by the application should be included here as well. 10) Generate the distributable file that constitutes the web application (war extension). 11) Configure the application server with the connection string and the jdbc driver according to the database engine. The connection name must match with the name defined in the datasource.properties file. 12) Deploy the application (.war file) in the application server.

Figure 3: General Java EE architecture defined for the product line members

As a result of following those steps, a functional web application is available to prepare it for final delivery to the customer. Then functional tests are required to ensure that this product satisfies customer requirements.

IV. DISCUSSION

The development of the SPL for applications based on biometric devices could bring several benefits to Acople Tecnológico, in addition to the several lessons that have been learned from the process of designing and development the SPL. In this section both of them are discussed.

A. Benefits for the Business

Acople Tecnológico changed its methods to build applications by applying a development paradigm with better results in development time and quality. In fact, given the need of Acople Tecnólogico to get to market fast, the old versions of the three products had evolved without much focus on design. As a consequence, it considered a lot of copy and paste of code and had many lines of code providing the same functionality but written in a different way. After follow the product line approach, all the developed core assets offer more functionality that their pre-product line counterparts with a reduction in the number of lines of code. This improvement is very useful considering that more lines of code would represent more troubles, especially during the maintenance phase. Another secondary benefit was the uniform look and feel and code style adopted after the full re-factor required in this process, considering that both aspects contribute to improve the final product quality. Furthermore, the SPL could be used to extend the portfolio of Acople Tecnológico's applications in the future, allowing them to envision new applications since different contexts could require the same functionality. Taking advantage of this opportunity, Acople Tecnológico already generated a new product targeted to preschool institutions, allowing them to register persons authorized to pick up each child and to identify who picked them each day. In this way, the school increases the security in the process of releasing the children to their families. This new product has many similarities with the Working Time one, and its set of features is one of the 320 combinations produced by the Variamos analysis.

In the same way, the SPL eases the creation of any of the three products including particular functionality required by a specific client. This was the case of a new variation of the Working Time application. Before the implementation of SPL methodologies, a particular request was attended by duplicating the application code -in this case, Working Timeand making further modifications over it. With the SPL, the basic application functionality is coded in libraries that are added to a new project, then specific functionalities are treated as new features, generating new libraries to implement them. Eventually, those new features could be included in the features model being available to use on new types of products.

Moreover, with the aim to facilitate the inclusion of new features or application types, the modules design, and implementation involved extension points. As an example, the component Marks has attributes to identify the application type and extra attributes to manage diverse data types (numeric, alphanumeric, or boolean).

Thus far, the SPL also facilitated the generation of a third new product that integrates the functionality of Working Time, Restaurant, and Access applications. With this product Acople Tecnológico served one client that wanted to use the three products. Before the SPL implementation, three different applications would have been sold and installed.

B. Lessons Learned

Several lessons have been learned during the analysis, design, and implementation of the SPL, among them, are the following ones.

The features model allowed us to abstract the problems and to focus development efforts on reusing artifacts, leading to high quality and functionality, reducing the development time and giving quicker customer response. This improves the company's business opportunity.

The variability model was useful to identify applications' modules. It includes business rules that guarantee high cohesion and low coupling, easing the reuse of components.

The modules' dependencies definition was crucial to avoid circular references and to achieve low coupling. Besides dependencies point out the components' implementation order. Moreover, as far as possible, a product derived from the SPL will contain only the logic associated with the features the product comprises.

Even though in our particular case the 320 feature combinations could be analyzed to select a set of new products that could bring the Acople Tecnológico's market attention, generally that is not a viable task due to the vast number of possible combinations. However, having the combinations is valuable since it allows us to verify if a particular set of product requirements is valid in the SPL. In fact, when a new client wants a product from the company, Acople Tecnológico can easily identify what requirements are covered by the product line and therefore could better estimate the cost and the development time required to satisfy them. If there are requirements that cannot be satisfied through the reuse of assets previously developed into the product line, the company negotiates and develops those requirements as a product-specific addition.

The development of an SPL in an SME could bring some advantages. Among them, the products are small like the organization itself, in the sense that they are composed of few components. This facilitates the analysis, design, and development stages, as well as the transition from the methodologies applied before to the new ones. However, there are also some disadvantages; the main one is that the organization has few human resources. Thus, maintaining the operation along with the development of the SPL is a demanding task.

Finally, the most complex task was to design the modules, maintaining the abstraction while increasing reusing. The experience of Acople Tecnológico in attending the biometric applications market was a key aspect in the definition of generic modules. The design facilitated the codification task since it provides a better comprehension of components' functionality. Thus, since benefits are greater than the cost of design and implementation of the SPL, Acople Tecnológico is planning to develop, in the near future, an SPL for the second set of products in their portfolio, related with auto service portals directed to employees, clients, and providers, among others.

V. RELATED WORKS

In recent years the industry has reported several experiences regarding the implementation of Software Product Lines. The Product Line Hall of Fame4 lists the best SPL industrial applications presented in the Software Product Line Conference over the years. Among them, Siemens Healthcare [START_REF] Kircher | Combining systematic reuse with agile development: Experience report[END_REF] combined SPL with agile development to overcome some challenges detected in the development of imaging products. Those products, ranging from medical scanners to visualization systems, share medical imaging functionality, including different image modalities, data types, analysis algorithms and manipulation concepts. The U.S. Army Live Training Transformation and the U.S. Navy command and control systems of Naval surface combatants [START_REF] Clements | Second generation product line engineering takes hold in the dod[END_REF] are two SPLs that bring improvements in quality, time to deployment, cost, and engineering productivity. Linden et al. [START_REF] Linden | Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering[END_REF] collect the experiences of eight companies, including Nokia, Bosch, Philips and Siemens, describing the main effects of the SPL adoption. Additionally, Koziolek et al. [START_REF] Koziolek | Assessing software product line potential: an exploratory industrial case study[END_REF] report the experiences from executing domain and economic analysis in more than 20 software systems belonging to four application cases in the ABB engineering company and concluded that SPL should be applied in only one of the four cases. They identified feature domains, subdomains and components with the potential to constitute a SPL. Pohl et al. [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF] present another fifteen successful implementations. The authors highlight the costs and development time reduction, as well as the improvement of product quality. Birk et al. [START_REF] Birk | Product line engineering, the state of the practice[END_REF] analyzed the SPL practices used by five organizations, among them Hewlett-Packard and Bosch. Laguna y Hernández [START_REF] Laguna | A software product line approach for e-commerce systems[END_REF] report the application of methods and techniques of the Product Line Engineering in the domain of e-commerce software and describe the modeling, configuration, design and implementation stages. Sanchez et al. [START_REF] Sanchez | Software product line engineering for e-learning applications: A case study[END_REF] report the development of an SPL to generate e-learning web mining products that include variations of three major features: e-learning platform, queries, and data mining suite. The authors describe the analysis of the domain and the application engineering processes. Parra et al. [START_REF] Parra | An soa approach for automating software product line adoption[END_REF] describe the implementation of SPLs in Heinsohn Business Technology. They developed a SOA modular architecture to support the adoption of a SPL over a set of JEE artifacts already developed for different domain applications.

Even though SPL has been applied in several domains, most studies refer to projects carried out in large companies. In contrast, in this paper, we report the experience and lessons learned from the SPL implementation in a small organization. Besides, different to other cases, in this work we adopted an extractive approach that took advantage of the Acople Tecnológico experience in the market. Moreover, even though biometric recognition is included as a feature in many SLP examples [START_REF] Faegri | A software product line reference architecture for security[END_REF], [START_REF] Kang | Applied Software Product Line Engineering[END_REF], to the best of our knowledge, there is no report of an SPL including biometric devices for authentication with an aim different to software access control. The software products obtained by the SLP presented in this paper use the authentication for other purposes, such as working time or restaurant consumption control.

VI. CONCLUSIONS AND FUTURE WORK

This paper has presented how a set of products that use biometric devices have been re-factored, using an extractive approach, into a Software Product Line. The crucial aim of introducing the product line approach in Acople Tecnológico was to improve reuse in a planned way, which means a reduction in the time and cost of developing new related products.

The approach developed in this paper presents the experiences and lessons learned from applying SPLE in a particular industrial setting. Doing so, we define a variability model expressed as a feature model that was inspired by a real case, and therefore may be used as a reference for future researches. Furthermore, we explain our general strategy to develop reusable components based on a compositional approach and the benefits and lessons learned from applying software product lines into an small enterprise.

So far we have come a long way in the implementation of our product line, but we are aware that there are other steps to follow in order to finish our goal. As a next step, we will continue extending our proposal. We aim to define a strategy for configuring and assembling as automatic as we can the modules that we have developed, which will allow us to create new products from the product line. We have considered tools as Gradle or Maven to automatize the assemble process. Moreover, we are interested in incorporate non-functional requirements such as security and availability into the SPL development to improve the current software assets.

Figure 1 :

 1 Figure 1: Feature model which represents the variability and commonality in the analyzed domain

Figure 2 :

 2 Figure 2: Detail design module Devices

http://variamos.com/

https://eclipse.org/downloads/packages/eclipse-ide-java-eedevelopers/mars2 respects the structure presented in Figure3. Then, we added to this project all the developed modules with the exception of the optional ones (see Notifications, Calendar, and Schedule modules ). As a result, we obtain a set of assets which not conform a full executable application because options and settings in the binary and open modules are still open at the module level, but are very useful to simplify the product derivation. In this sense, by first defining the common aspects between the products instead of specifying their differences, we give a basic reference frame, but we still allow freedom in product specific architectural deviation.

http://splc.net/fame.html

ACKNOWLEDGMENTS

This work has been partially supported by the Pontificia Universidad Javeriana Cali, Colombia, under the program COFINPRO2014 which sponsors the Project No. 4127.