invariably reduces the capabilities of the resulting system [Murray, 1999].
Identify the students: It is of utmost importance to also identify, in the design of ITS authoring tools, the students who might learn in several different contexts (workplace, home, school, and so on), at several levels (middle-school, high-school, college, and so on), and whether students are, for example, workers or trainees [Woolf, 2010].
In this thesis, we consider all these design issues to propose our authoring solution, as will be further explained in Chapter 6.
2.4
Feature modeling and software product line
As previously explained, in this thesis we conceptualize the design space of ITS by conducting a feature modeling activity. This activity is one of the key steps to develop software product lines, thus, in order to contextualize the use of this activity in our work, we generally describe some software product line concepts.
The most important aspect provided by SPLs is the systematic reuse of all artifacts in the software development process. This systematic reuse is supported by two fundamental principles: reusable platform and customization [Pohl et al., 2005]. A reusable platform involves the identification of all common features of a family of products and the specification of these commonalities in all assets of the SPL. We mean by assets all artifacts that constitute a software development: requirements, software architecture, code, tests and so forth [Clements and Northrop, 2001]. In order to provide the customization of the products in a software product line, the notion of variability is also explored in all artifacts that are developed.
Software Product Line Engineering [Pohl et al., 2005] defines a process that specifies a set of activities of software development that supports the systematic creation of software artifacts aiming to manage the commonalities and variability of an SPL. There are two specific sub-processes to each one of the essential aspects of an SPL: (i) Domain Engineering - responsible for establishing a reusable platform and defining common and variable aspects of a software product line for a given domain, it consists of all types of software artifacts; (ii) Application Engineering - responsible for deriving the product line application from the
2.4 Feature modeling and software product line 33
platform established in the domain engineering. It exploits the variability of the product line and ensures that variability is consistent with specific needs of an application.
2.4.1
Feature Modeling
The variability of SPLs is commonly expressed through features represented in feature models. A feature is a property of the system that is relevant to some stakeholder and is used to capture similarities and variabilities of software systems. Feature modeling has been proposed as an approach for describing variable requirements for software product lines [Czarnecki et al., 2006]. It is an important activity of the software product line development process, since it is in such phase that the common and variable features of the product family are specified.
Features are organized in feature models according to one of the following types:
• Mandatory – the features in this category must be present in all products derived from
a software product line;
• Optional – a feature of this type may or may not be included in a product derived from
an SPL, hence its presence is optional;
• Alternative – in the alternative feature, exactly one feature from a set of features must
be included in a product;
• Or-feature – one or more features from a set of features can be included in a product
from an SPL.
The most widely used technique for modeling features was originally presented by Kang et al. [1990], named Feature-Oriented Domain Analysis (FODA). FODA provides a graphical tree-like notation that shows the hierarchical organization of features. The root of the tree represents the whole SPL node and all other nodes represent different types of features that are part of an SPL.
Figure 2.5 presents an example of a smartphone SPL feature model represented in the
FODA notation. This feature model was adapted from a repository1of feature models and is
used to illustrate this notation. 1Available at
2.4 Feature modeling and software product line 34 ^ŵĂƌƚƉŚŽŶĞ ^W> ^ĐƌĞĞŶ ĂƐŝĐ ŽůŽƵƌ ,ŝŐŚͲ ƌĞƐŽůƵƚŝŽŶ ĂŵĞƌĂ DWϯ ZĂĚŝŽ ZĞƋƵŝƌĞƐ džĐůƵĚĞƐ ŶĚƌŽŝĚ ŝK^ tŝŶĚŽǁƐ WŚŽŶĞ DĂŶĚĂƚŽƌLJ KƉƚŝŽŶĂů ' ' ' &ϭ &Ϯ ůƚĞŶĂƚŝǀĞ ĨĞĂƚƵƌĞƐ ' &ϭ &Ϯ KƌͲ&ĞĂƚƵƌĞƐ <ĞLJ džĐůƵĚĞƐ &ϭ &Ϯ ZĞƋƵŝƌĞƐ &ϭ &Ϯ & & KƉĞƌĂƚŝŽŶĂů ƐLJƐƚĞŵ Ăůů 'W^ &ůĂƐŚ DĞĚŝĂ
Figure 2.5: Smartphone SPL features model in the FODA notation
Figure 2.5 shows the graphical notation of each type of feature (mandatory, optional, alternative and or-features). Mandatory features are graphically represented by a small, filled black circle above the feature name (e.g., Operational system, Call, and Screen). Optional features are graphically specified by an open, non-filled white circle (e.g., GPS, Flash, and Media). Alternative features share the same parent’s feature and are graphically represented by an open arc situated just below the parent’s feature (e.g., Android, iOS, and Windows Phone). Finally, the or-features (e.g., Camera, MP3, and Radio) are represented by a filled arc, similar to the alternative features.
Additionally, in the feature modeling using FODA notation, it is possible to represent dependency rules between features, which can be one of two types: (i) Requires, when one feature requires the existence of another feature (they are interdependent), and (ii) Excludes, when one feature is mutually exclusive to another one (they can not coexist).
One of the contributions of this thesis is identifying and representing in the FODA notation, a feature modeling for gamified ITS. This model is further described in Chapter 4.