TESMA: Requirements and Design of a Tool for Educational Programs ^†

Abstract

Defining and managing teaching programs at universities or other institutions is a complex task for which there is not much support in terms of methods and tools. This task becomes even more critical when the time comes to obtain certifications w.r.t. official standards. In this paper, we present an on-going project called TESMA, whose objective is to provide an open-source tool dedicated to the specification and management (including certification) of teaching programs. An in-depth market analysis regarding related tools and conceptual frameworks of the project is presented. This tool has been engineered using a development method called Messir for its requirements elicitation and introduces a domain-specific language dedicated to the teaching domain. This paper presents the current status of this project and the future activities planned.

1. Introduction

The University of Luxembourg [1] is a young university (created in 2003). The Grand Duchy of Luxembourg is a multicultural, multilingual country in Western Europe located at the intersection of France, Germany and Belgium. Its only public university was founded in 2003 and embodies its multicultural spirit. In 2016, 860 professional experts from 20 different countries were working in different departments and research areas. In this multicultural “start-up” context, we have been setting up new programs at bachelor, master and doctorate levels providing different education certificates. All of those programs are offered to 6172 students from 115 different countries by our three faculties. The need for a tool to support the task to define and manage (including certification) the education program came rapidly. The market analysis for this category of tools showed that no tool was available. A project has been started to engineer a method and a tool to support those needs. This project has been conducted following a software engineering process that had the following main steps:

• Requirements analysis: to provide the initial requirements for the TESMA tool, a requirement specification document has been produced using the Messir method [2].
• Design: to state the main choices concerning the TESMA architecture and interfaces.
• Implementation: to reach an operational system usable for validation w.r.t. the requirements.
• Those steps have been performed iteratively to produce the TESMA tool in an incremental way.

The content of this article provides details on the requirements analysis and design of the TESMA tools. This article extends our conference paper [3] by providing the following additional content: two extensive surveys exploring existing tool features and the conceptual frameworks used by a number of educational institutions carefully selected over the world; and based on the surveys’ results, the presentation of a new architectural component, the Moodle page generator, in Section 2.3.4.

2. Results

2.1. Surveys

We have performed two surveys in the context of the TESMA project. On the one hand, a large number of tools related to the handling of educational programs have been surveyed; on the other hand, educational conceptual frameworks of international institutions have been explored. Section 4 describes the methods and materials that we used to produce the results of the surveys presented in this section.

2.1.1. Survey on Educational Programs Management Tools

This survey has been performed in two steps: a primary study and a secondary study [4] (in this article, we are using some of the terminology introduced by Kitchenham et al. [4] applied to the context of our article, i.e., our technological watchdog survey and our conceptual frameworks survey). The main objective of this tool survey is, taking as input the set of TESMA requirements that we elicited, to search for existing tools such that we are able to choose between:

• Extending an existing tool or
• Implementing a new ad hoc tool

The primary study explored the existing tools, related to our required feature categories. This primary study resulted in a collection of around 200 different tools related to educational program management. Then, based on this large set of tools, we have performed a secondary study, which resulted in a reduced set of 27 tools, listed in Appendix A.

During the TESMA requirement elicitation phase performed prior to this survey, we had identified 373 different features grouped in 101 different categories that define the required feature categories for our TESMA tool to be implemented. The names of these feature categories are listed in Appendix C. During the secondary study, for each of the 27 tools, we have identified the operations provided by the tool based on its documentation and on its publicly available documentation. Each identified tool operation has been mapped to one of the TESMA feature category that we defined.

Table 1. The six most interesting tools resulting from our study and their coverage w.r.t. the TESMA features categories.

Tools	TESMA Features Categories
	Covered	Not Covered	Coverage
Moodle	52	49	52%
Fedena	43	58	43%
Sakai Project	34	67	34%
Schooltool	22	79	22%
Canvas	16	85	16%
D2L	15	86	15%

presents the feature categories coverage for the six most interesting tools. We can note that the closest tool to TESMA in terms of feature categories coverage is Moodle. (Note that in terms of features coverage Blackboard [5] is closely related to Moodle, but we could not survey it because of not being able to access to a demo license. Anyhow, this tool is not open-source, thus would not have been compatible with open-source orientation of TESMA.) Moodle is an open-source learning management system that supports the description of programs and courses; and the sharing of information and course material between teachers and students.

With respect to our study objective, as a result of our secondary study, we conclude that there is not any tool covering enough of the TESMA feature categories. The best tool being Moodle with a coverage of our feature categories of around 50%. Thus, we have decided to:

• implement an ad hoc tool, providing the feature categories not covered by Moodle, e.g., specification of educational programs with a DSL, and
• implement a Moodle page generator component in our tool that creates Moodle-compliant web pages, presented in Section 2.3.4. The objectives of this new component are two-fold:

  (a)

  benefit from the existing web front-end of Moodle.

  (b)

  ease the adoption of our tool by Moodle users.

2.1.2. Survey on Educational Programs Concepts

Based on the TESMA tool’s requirements analysis specification, presented in Section 2.2, we performed a conceptual framework survey. This survey consists in studying the concepts used in existing educational programs of carefully selected universities in the world.

The main objective of this conceptual frameworks survey is to validate the set of our TESMA domain concepts, presented briefly in Section 2.2, by:

• Evaluating if the TESMA domain concepts cover all the concepts of the selected universities. This would answer a question like: does the current TESMA concept model contain enough concepts to specify all the educational programs needs of the selected universities?
• Evaluating the coverage of the existing universities’s concepts against the full set of TESMA domain concepts. This evaluation would give a quantitative hint on how much more concepts could be covered by the selected universities if they would use our TESMA tool.

This study has been performed on a set of 10 universities listed, together with their websites and programs, in Appendix B. During the TESMA requirements analysis phase, we had identified 85 domain concepts. The survey of education programs concepts consisted in the analysis of the concepts of the selected institutions and compared them with the 85 TESMA domain concepts. Our study showed us that the surveyed institutions are often using different naming conventions, except for general concepts like courses, elective courses, programs, etc., even though, all universities’ concepts might differ in their naming conventions or internal structure, their semantics are often compatible.

Table 2. Results of the survey on the 10 universities’ conceptual frameworks.

Universities	Institutions Concepts				TESMA Concepts
	Covered	Not Covered	Total	Coverage	Coverage
University of McGill	37	0	37	100%	44%
The Hong Kong University of Sci. and Tech.	17	0	17	100%	20%
University of Geneva	14	0	14	100%	17%
King Abdulaziz University	17	1	18	95%	20%
University of Luxembourg	50	5	55	91%	59%
Innopolis University	14	2	16	88%	17%
University of Southern California	24	4	28	86%	29%
University de Rennes 1	9	3	12	75%	11%
National University of Singapore	18	7	25	72%	22%
The University of New South Wales	12	5	17	71%	15%

presents the results of the universities conceptual frameworks study. The table shows the selected universities, with the number of concepts that we identified for each institution, the number of institution concepts that match with TESMA concepts (or not). The covered institutions concepts are concepts that we considered to be compatible in terms of their informal semantics with TESMA concepts. We also display, for information, in the last column of the table, the proportion of the university concepts in terms of the overall TESMA concepts defined.

With respect to our study objectives, this conceptual frameworks study reveals that:

• most of the universities concepts are covered in TESMA, at a proportion of 70% or more. Thus, it is possible for universities to use the TESMA conceptual framework to specify most of their concepts.
• the coverage of TESMA concepts by all institutions is rather low, below 50%. This is partly due to the low number of universities having a course certification policy. Thus, most universities would gain using our domain model, it would improve the number of concepts used in their educational programs specifications.

In order to attract a larger set of institutions, a generic tool needs to be developed. This tool needs to be adaptable to the universities concepts and naming conventions. Underlying to this tool’s requirements, the first version of the TESMA concept model will need to be improved. These constraints will improve the compatibility of the tool at other institutions and increase the institutions concepts coverage to 100%.

2.2. TESMA Requirements

Following part of the Messir method [2], presented shortly in Section 4.2, we have elicited the actors that are concerned by teaching programs. They are:

• The institution director who represents the institution and validates new programs, courses and course modifications (e.g., the dean of a faculty, the head of a teaching unit, etc.).
• The program director who specifies his programs and validates course modifications made by instructors.
• The instructor, who specifies, manages and maintains the courses he gives.
• The student, who tunes his curriculum (elective courses, etc.) and receives information about his curriculum.
• The secretary, who is a delegate of any of the institutional actors (institution director, program director or instructor) and also ensures interoperability with other institution information systems.
• The quality officer who evaluates and validates the programs with respect to the universities internal laws. He’s also responsible of program certification processes.

You can find in Figure 1, a use-case model made in the context of the Messir method that displays the actors contributing to the high-level summary use-case dedicated to managing a teaching program.

The concepts managed by the TESMA actors are analyzed and specified in the Messir concept model which is an UML [6] class diagram. Concept models diagrams are partial views on the domain concepts handled by the system under study. The concept model can be seen as a result of domain analysis. Among all the concepts that are necessary to specify the operations executed by the actors we have:

• concepts related to the actors and for which TESMA has to handle an internal representation: students, instructors, etc.
• concepts related to the programs: course details, teaching periods, course evaluation, etc.
• concepts related to program certification: standard description, standard coverage by an existing program, etc.

In Messir those concepts are specified using an UML [6] class diagram, Figure 2 provides a partial view on some of the concepts related to a program (institution, program, courses).

The requirements analysis phase has allowed to determine a first version of the functionalities and data that should be handled in the first increment. The next section presents the design of this first version.

2.3. TESMA Tool Set Development

After having analyzed the TESMA actors, concepts and functionalities, we have started to design a first version of the TESMA tool set. A major design choice made is to allow the specification of programs using a Domain-Specific Language (DSL) [7] defined using the Xtext [8] framework. Xtext is an open-source framework for the development of textual domain-specific languages and the creation of textual editors. Thus, we have designed TESMA as an Eclipse plugin, i.e., a java program extending the Eclipse workbench [9]. Eclipse is an open-source extensible development workbench that benefits from a large community of developers. TESMA is composed of four main architectural components illustrated in Figure 3 at the top of the diagram. Our components are based on stable Eclipse plugins themselves based on the Eclipse Modeling Framework (EMF) [10]. EMF is an open-source modeling framework part of the Eclipse workbench providing tools to manage structured data models. EMF is used as the underlying core library handling the TESMA model.

In the following sections, we present the different component of the TESMA plugin: textual editor, graphical editor, documentation generation, Moodle page generator.

2.3.1. Textual Editor

This section presents the features of the Textual Editor; and the design, implementation and test cases of the grammar of the TESMA DSL [11] used for specifying the teaching programs and courses.

The main feature of the Textual Editor is to allow the specification of the teaching programs (this specification is called TESMA model in the remaining part of this paper) with the TESMA DSL. It also offers other supporting features, as for instance: syntactical validation rules, syntax highlighting, templates proposal, auto-formatting, scoping, quick fixes and auto-completion, hovers, outline view, compare view, code folding, etc. The aim of these features is to support the specifier during the specification of the TESMA model. These features improve the readability, understanding, accessibility and validation of the specification. The time to understand and to learn how to use the syntax is reduced by using proposals, auto-formatting and auto-completion. Thanks to the outline view, the user has a graphical overview of his/her specified TESMA models. Parts of the specification can be hidden using code folding to improve the readability. The syntactical validation rules and the auto-completion help the user of the DSL to improve the learnability of the syntax and specify effectively a valid TESMA Model. The result from concept model analysis, partly shown in Figure 2, has been taken as input for the design of the DSL and in particular for the specification of its grammar in Xtext.

The TESMA DSL is designed to be intuitive, customizable and loosely-coupled. In order to have an intuitive DSL, we have chosen to design its grammar using mainly keywords in natural language. Institutions often use different terminologies for the concepts used in our approach, this is why we designed the grammar of our DSL to be customizable. The institutions have the possibility to choose their own naming conventions. Our design should allow non-computer experts to use the TESMA DSL as it uses natural language keywords, no logical operators and control flow statements. The rules of the grammar are loosely coupled, i.e., optional cross-references are mostly used instead of containment relations. Lastly, thank to loosely coupled grammar rules, TESMA supports multiple user specifications. The TESMA model can be specified independently by different persons. Thus, the specifications can be merged together afterwards.

The TESMA DSL has been implemented using the Xtext framework. During the DSL design, we mapped the identified concepts to Xtext grammar rules. The grammar represents the metamodel of TESMA models. It has been developed in the .Xtext file of the parent Xtext project and consists of a set of rules that represent the syntax of the TESMA DSL. The following types of rules are used to develop the grammar: fixed keywords, user-dependent keywords, consecutive words, optional words or complete phrases, different types of relations, etc. Figure 4 shows a part of the TESMA grammar that illustrates the fundamental TESMA concepts (institutions, programs, courses). Once the grammar has been defined, an EMF Ecore model and a generator model (genmodel) has been generated using the Xtext artifact generator. The EMF Ecore model contains basic information about the defined grammar, e.g., classes, attributes and relations. The genmodel contains some additional properties for the code generation that are not part of the metamodel itself, e.g., generated source code, path and file information. A part of the generated source code is the model validation code, the scoping and a generator class. Thanks to the code generation, the validation of the TESMA model has been developed inside the TESMA validator. A set of rules has been defined to help the specifier to correctly specify TESMA models. The scoping allows a user defined content assistant and linking. Thanks to the generator, we have generated plenty of documents, see Section 2.3.3.

In our tooling context, we present two possible ways to test the TESMA DSL. One possible choice is the unit testing feature of Xtext. Using this feature, we are able to implement automated test that check if a piece of the source code is correct for some particular case. The unit testing feature uses JUnit [12] as unit testing framework for Java applications. The aim of these unit testing features is to improve the maintainability and quality of the software product. Xtext supports such testing on the textual editor or on the metamodel itself. A second possibility is to test the TESMA DSL using some concrete examples. Our test cases are based on the University of Luxembourg with its three faculties and its various teaching programs that propose courses in plenty of different domains. To test the features, the validation and the usability of our grammar, we have specified one course given in a program of the University of Luxembourg, see Figure 6. These four development steps, Design, Features, Implementation and Test are executed iteratively.

2.3.2. Graphical Editor

The Graphical Editor provides a representation of the TESMA model in a tabular view and offers the possibility to modify the TESMA model. The graphical editor provides typical table handling features like data sort, import/export from/to Excel sheets, hide/show columns, multiple rows selections.

The technology used to develop our graphical editor is Sirius [13], an open-source software Eclipse project that eases the creation of custom graphical modeling workbenches. Both Xtext and Sirius are based on EMF, which allows the TESMA tool-support to interact between Xtext and Sirius using EMF as underlying-core library for the TESMA model as represented in Figure 5.

Thanks to our tabular format, the graphical editor is intuitive and usable by non-computer experts. All the program’s attributes are easy to access and modify. The modifications can be performed directly inside the graphical editor view.

2.3.3. Documentation Generator

The main feature of the documentation generator is to generate documents of different types, like Excel sheets, CSV files and PDF files. The documentation generator may be configured to produce a customized PDF file, e.g., by not generating some of the sections inside the pdf files.

The technologies used to develop the documentation generator are Xtend [8], Latex and the apache.poi library, for handling Excel sheets. Xtend is a programming language based on Java. It provides a compact syntax and eases the generation of natural language text. Latex is a document preparation system, which uses libraries, keywords and plaintext for writing scientific documents in pdf format. Finally, the apache.poi library provides the necessary tools for generating Excel sheets, which are used as teaching material.

The documentation generator has been designed to ease information retrieval in the generated Latex files. Additionally, it is designed to automatically update the final report, when the user manually adds data into the reserved appropriate folders. Finally, the different Latex files are imported inside one Latex file, which is compiled into a pdf file containing the program description.

2.3.4. Moodle Page Generator

The main feature of the Moodle page generator is to generate Moodle web pages displaying the content of the courses specified as a TESMA textual specification.

The current design is to use the Moodle APIs to create as much information as possible in the Moodle site using the web services provided. The technologies used to develop the moodle page generator are: on the one hand, REST web services offered by Moodle called using HTTP protocol in order to create a new page or a new use account in the TESMA Moodle server; on the other hand, execution of SQL queries modifying directly the Moodle server’s SQL database, for the features that are not yet implemented as REST web services.

Current experimentation implementation of this component support one-way generation, i.e., taking as input TESMA specification of courses and configuring a Moodle website to display the courses specified.

2.4. Illustration

We illustrate the TESMA approach with a course of a Master program named “Software Engineering Environment” (SEE) at the University of Luxembourg. Figure 6 is a screenshot of the TESMA tool-support in the Eclipse environment.

The TESMA model describing the SEE course has been specified using the approach described in this article. The teaching program description of this example includes a number of textual files using the TESMA DSL syntax. The course run information is illustrated in Figure 6 by specifying the course teaching team organization and dividing the teaching term into small periods and defining the tasks, tests for each period. The tasks and tests are defined in separate folders and referenced to the teaching period. At that point, TESMA is able to generate a part of a Moodle page, the Teaching Material, like evaluation criteria, task lists and course information. Figure 7 and Figure 8 are screenshots of the generated moodle page based on the SEE course described with the TESMA specification resp. screenshots of the course syllabus of the SEE course that is included inside the generated TESMA report pdf file.

All other concepts can be specified using the TESMA DSL including the coverage of an education standard by an education program.

In this case study for the SEE course, we created for each category of TESMA model element a file containing all information related. In this case, one institution, one program and one course have been specified, which represent about 10 textual files. We defined 10 instructors and seven students for this example case, which are grouped in a single file. The total description in our case needs about 500 lines of specification text (>1000 in case of certification). The specification text size mostly depends on the preciseness of the specifier. If the specification is done in details, the number of lines increases quickly. In general, it could vary from 100 to 1500 lines.

3. Discussion

Before starting our market analysis, we looked at the state of the art and a first set of high level requirements that define our research criteria. These requirements are describing a subset of the program and course specification needs based on the University of Luxembourg.

Currently at the University of Luxembourg, Acrobat Reader, Microsoft Word, Excel and PowerPoint are widely used for describing, managing and assessing their programs. The program directors and teachers are often starting their description from scratch and without any method. Some universities may provide templates, that has to be filled out and sent to the administration office. This current approach has some advantages:

• familiar environment
• simple basic functionalities (filling out the cells, text formatting, etc.)
• simple installation
• export possibilities
• usable with many operating systems (Windows, MacOS, Linux, etc.)

and a lot of disadvantages:

• very costly (Acrobat Pro 15$/user/month and Microsoft Office about 10$/user/month)
• exhaustive specification task without templates
• lack of methods for specifying a program
• the use of Excel formula might be complicated even after following a training program
• collaborative and simultaneous work is impossible
• low performance if the document is very large and contain a large dataset
• entering large datasets manually to Excel is very time exhaustive
• inflexible auto format tools, bugs in format options
• it is very hard to maintain (no version control)
• loss of data in case of corrupted and damaged files

The University of Luxembourg provides MS Word templates for specifying the programs and registering the administration office. It is possible to describe a whole program and their courses using these templates. The instructors have to fill out the required fields and sent the specification to the secretary via email. Due to the missing specification methods, the teachers are free to write their own specification. They do not have any restriction on the content that may lead to some problems. Teachers often do not know how to describe their programs resp. courses. Most institutions do not even organize training sessions for their teaching staff. The following problems may occur:

• incomplete and unstructured program and course specification
• misunderstandings in between the university and the program/course holder
• misunderstandings in between learners and program/course holders
• incomparable documents
• not standardized to some international learning standard
• old and not maintained course specifications

For managing the course runtime and distributing the teaching material, the university of Luxembourg is using Moodle. Moodle is an open-source learning management system. Programs and courses may be described inside the tool. The teachers share information and course material using that platform.

Thanks to our analysis of the state of art, we were able to define a first set of high level requirements, that helped us to retrieve tools that could cover our needs. We were looking for tools that allow the static specification of institutions, programs and courses, dynamic specification during the course runtime, maintainable program specifications, the possibility to specify a program according to some international learning standard for accreditation purposes and the possibility to generate specification documents that may be distributed to the interested parties.

4. Materials and Methods

In this section, we aim at describing the materials and methods used to build the results, presented in Section 2, in order to allow potential reconstruction of our results by the readers (Note that the results from web search engines are unfortunately rarely reproducible, as their computation depends on a number of factors, as for instance the user performing the search, his/her geographical location, history of search, etc., most of these factors being totally unknown).

4.1. Surveys

4.1.1. Educational Programs Management Tools Survey

Here is the method that we have followed to construct the results for the educational programs management tools survey.

• Firstly, the need for the survey has been identified and described in terms of the main objective presented in Section 2.1.1.
• Then a survey protocol has been planned and executed for the primary study:

  • The strategy for searching is to use the Google search web engine with some keywords related to the TESMA domain: “tool” AND (“syllabus” OR “educational program” OR “education” OR “curriculum” OR “institution” OR “university” OR “school” OR “certification” OR “specification” OR “management”).
  • No specific criteria have been set to discard any data resulting from the search.
  • During this primary study the data extraction consisted in a textual listing of the website URLs of the resulting tools.
  • Two researchers of our team have performed this search. The result of this primary study has been the union of the two researchers’ results.
• A secondary study has been planned and executed

  • The secondary study input were the results from the primary study, i.e., the list of websites URLs.
  • Some selection criteria have been defined, in particular, we excluded all tools from the primary study that

    –

    do not provide ways to specify educational programs, which is one of the main contribution of TESMA.

    –

    do not provide course runtime management, which is also an important feature of TESMA.

    –

    are e-learning platforms, which are not the focus of our project.

    –

    programs for which the coverage of TESMA feature categories were too low, i.e., less than 5% coverage.

  • The format of the extracted data has been performed systematically using a Google sheet “database” following this format, for each table’s row: the name of the tool, an operation provided by the tool, our feature category in which it can be mapped, a textual description of the operation, and the URL from which the description has been extracted.
  • The strategy used has been to

    –

    Study the online available documentation of the tool, e.g., user manuals or tutorials.

    –

    When available, we also installed the demo version of the tool and experimented it in order to extract implicit tool’s operations.

• the data has been synthesized using pivot tables from the Google sheet table containing the extracted data. These pivot tables have then been inserted in the content of the present article in Table 1,

  Table A1. List of surveyed tools during the secondary study.

  	Tool Name	Founder	License Type	Reference
  1	TESMA	University of Luxembourg	open source	[3]
  2	SchoolTool	Shuttleworth Foundation	open source	[16]
  3	Moodle	Moodle	open source	[17]
  4	Sakai	Apereo Foundation	open source	[18]
  5	Open Education Resource	OEDb	proprietary	[19]
  6	Ariadne Moodle Search Widget	Ariadne Foundation, Eummena	unknown	[20]
  7	Responsive Open Learning Environments	Ariadne Foundation	open source	[21]
  8	Learning Resource Exchange	European Schoolnet	proprietary	[22]
  9	Atutor	Atutor	open source	[23]
  10	Canvas	Canvas LMS	proprietary	[24]
  11	Claroline	Claroline Connect	open source	[25]
  12	Curriki	Curriki	proprietary	[26]
  13	D2L	Desire2Learn	proprietary	[27]
  14	EduCommons	EduCommons	open source	[28]
  15	Joomla LMS	Joomla	proprietary	[29]
  16	LAMS	LAMS Foundation	open source	[30]
  17	LRN	LRN	open source	[31]
  18	Olat	University of Zurich	open source	[32]
  19	Open Tapestry	Open Tapestry	unknown	[33]
  20	Fedena	Foradian	proprietary	[34]
  21	OSM	University of Alabama	proprietary	[35]
  22	Concourse–Syllabus Management	Intellidemia	proprietary	[36]
  23	Alma	Alma	proprietary	[37]
  24	Schooltime	Schooltime	proprietary	[38]
  25	Educube	Educube Division	proprietary	[39]
  26	UOnline	University of NewCastle	unknown	[40]
  27	Blackboard	Blackboard	proprietary	[5]

  and

  Table A3. TESMA feature categories.

  Category	Subcategory	SubSubcategory	T${}_1$	T${}_2$	T${}_3$	T${}_4$	T${}_5$	T${}_6$	T${}_7$
  archive system	course history	course history			x	x			x
  	student history	student history						x	x
  backend operation	backend operation	backend operation	x		x	x	x	x
  course	course	course				x			x
  		participation management	x		x	x		x	x
  	course description	course description		x		x			x
  		dynamic course evaluation							x
  		dynamic task management		x	x	x	x	x	x
  		learning targets	x			x			x
  		lecture description				x	x		x
  		textual description	x			x			x
  	course resources	book				x			x
  		course creator						x	x
  		digital media			x		x
  		external package				x
  		hardware		x	x	x	x		x
  		human grouping		x	x	x	x	x	x
  		learner				x			x
  		teacher						x	x
  		textual document				x
  		weblink	x			x
  file management	file explorer	file explorer				x
  		file handling operation	x				x
  		one level grouping	x		x			x	x
  		reflexive grouping				x			x
  generation	documentation	documentation			x			x	x
  		evaluation report			x				x
  		user report				x			x
  		excel table generator							x
  		moodle page generator							x
  		participants statistics							x
  	statistics	grading statistics			x	x	x		x
  geographicallocation	geographical location	geographical location							x
  gui	assistance	assistance	x		x	x	x
  		highlighting			x	x
  	performance	performance			x		x	x
  institution	institution	institution							x
  		institution description							x
  interactions	intercommunication	contact management			x	x		x
  		intercommunication			x	x
  		mailing		x	x	x	x	x
  		real-time conversation					x
  	knowledge transmission	knowledge collection			x	x
  		knowledge exchange	x	x	x	x	x
  	notification	alert			x	x	x		x
  		announcement	x		x	x	x		x
  	submission	auto evaluation					x	x
  		categorized grading	x	x		x		x	x
  		customizable grading		x	x		x		x
  		graded evaluation		x	x	x	x		x
  		learning training		x		x	x		x
  		numerical grading							x
  		overall grading			x	x	x	x	x
  		ranked evaluation			x				x
  learning standard	learning standard	learning standard desc.			x				x
  multi-platform	multi-platform	multi-platform			x		x	x	x
  		textual editor							x
  		webapp							x
  		sirius							x
  		office							x
  other	other	other			x	x	x
  program	program	program				x			x
  		program description							x
  		program summary							x
  		program organization							x
  		courselist							x
  time management	calendar	calendar			x	x			x
  		course time management		x	x			x	x
  		evaluation time management					x		x
  		event time management			x	x	x		x
  		learning time management				x			x
  		task time management					x		x
  	time management	time management							x
  		semester planning							x
  		lecture planning							x
  tool operations	automatised operation	calendar creation			x		x	x	x
  	Create-Read-Update-	operation course handler	x		x	x	x		x
  	Delete operations	operation evaluation handler		x	x	x			x
  		operation grading handler	x	x	x	x	x	x	x
  		operation user handler	x		x	x		x	x
  	importation	external course description		x		x			x
  		external hardware	x		x
  		external software		x	x	x	x
  		external user data	x		x
  		external course evaluation							x
  	information retrieval	information retrieval			x	x	x		x
  		find course							x
  		find program							x
  		find semester							x
  tool requirements	language	language			x	x	x	x	x
  	performance	performance				x			x
  	scalability	scalability				x	x		x
  user access rights	evaluation access rights	evaluation access rights				x			x
  	file access rights	file access rights					x
  	user access rights	user access rights			x	x		x	x
  	user authentication	user authentication				x	x		x
  user management	user management	actor			x				x
  		user information							x
  		user details							x
  		user location							x
  		user management				x			x

  Legend of Table A3: T${}_1$: Canvas ; T${}_2$: D2L; T${}_3$: Fedena ; T${}_4$: Moodle ; T${}_5$: Sakai Project; T${}_6$: Schooltool ; T${}_7$: TESMA.

  .

4.1.2. Educational Program Concepts Survey

Here is the method that we have followed to construct the results for the educational programs concepts survey.

• Firstly, the need for the survey has been identified and described in terms of the main objective presented in Section 2.1.2.
• Then a survey protocol has been planned and executed for the primary study:

  • We have identified ten universities with different cultures and locations.
  • We have explored their websites and documentations publicly available.
  • The data extraction has been performed systematically

    –

    We have analyzed the syllabi of each universities, focusing on software engineering educational programs, or more general computer science educational programs.

    –

    For each concept implicitly, or explicity, used in the description of the program, we extracted the information and stored it in a Google sheet, that served us as a database.

    –

    each concept extracted, has been mapped, when possible to similar identified concepts of the TESMA requirements analysis model. Then also assigned to a category of concepts.

• the data has been synthesized using pivot tables from the Google sheet table containing the extracted data. These pivot tables have then been inserted in the content of the present article in Table 2 and

  Table A2. List of the selected institutions in the educational program concept survey.

  	Institution Name	Educational Programs Surveyed	Website
  1	University of Luxembourg	bachelor, master	[1]
  2	University of McGill	bachelor, master	[41]
  3	University of Southern California	bachelor, master	[42]
  4	University of Geneva	bachelor, master, long-life-learning	[43]
  5	University of Rennes 1	bachelor, master	[44]
  6	The University of New South Wales	bachelor, master	[45]
  7	Innopolis University	bachelor, master	[46]
  8	King Abdulaziz University	bachelor, master	[47]
  9	The Hong Kong University of Science and Technology	bachelor, master	[48]
  10	National University of Singapore	bachelor	[49]

  .

4.2. TESMA Tool Set Development

We use the Messir methodology [2] for the specification of the TESMA tool set requirements. This methodology comprises a set of models (use-case, concept, environment, operation, etc.) for the specification of the requirements analysis software development phase. The specification is performed using a textual DSL and views may be created in a UML-fashion [6]. From the numerous types of models proposed in this approach, we mainly used in the context of this article, the use-case and the concept models types that allow on the one hand to specify the interaction of the system with the actors of its environment; and on the other hand to specify the domain concepts handled by our system (i.e., TESMA tool set).

5. Conclusions

In this article, we have presented in-depth surveys that showed us that we did not find a similar educational tool covering all our needs. The selected tools might not be applicable to different types of universities. This was a motivation for us to create our own tool that can be used by a large number of universities worldwide.

We have presented the current status of our tool development allowing educational institutions to specify educational programs and courses. The tool uses a textual domain-specific language with a graphical editor and includes a moodle generator that allows the specifier to generate complete moodle pages for the diffusion of course information and material.

As future work, we plan to iterate the process presented in this article to stabilize the requirements and the tool design and implementation. We also plan to study the automated generation of a web application from the language grammar in order to provide a user-friendly front-end that is mapped to our textual language grammar and provide a better coverage of our targeted TESMA features. We could take advantage of the translational semantics defined in the Messir methodology [2] to verify some properties of the TESMA models using the translated prolog specifications of our TESMA models. We plan to make our tool more generic and adaptable to the different kinds of terminologies used by universities over the world; this will involve the design and specification of a configurable grammar for our DSL. In order to ease the specification phase, we also plan to offer some libraries offering some kinds of templates that will be used as skeleton specifications directly in our tool.