SPL [7, 28] is an approach to developing families of systems based on using reusable assets to improve software quality and reduce production costs and time to market. The products developed with an SPL are specified in terms of various features. A feature is defined as an increase in the functionality of the product, and an SPL can offer both common and variable features. An FM [9, 29-30] can be used to provide a compact representation of all the products of a product line in terms of features and relationships between them. FMs can specify which elements of the product family are similar or variable throughout the development life cycle. In addition, FMs can incorporate a set of rules in the form of logical expressions formed by features, logical connectives, and quantifiers. The reason for using predicate logic to express default rules is to avoid the ambiguities of natural language.

Several tools [31] support the development of feature-oriented software. Among these, we selected FeatureIDE [11] as the framework for the present study. Fig. 1 presents an FM represented in the FeatureIDE tool. The FM nodes represent features, and the lines indicate the relationships between them. The root node, A, represents the domain concept being modeled. The features of the model are classified as mandatory, optional, or alternative. Optional features, such as node C, are represented with an empty circle and may or may not be part of a product. Mandatory features, such as nodes B, D, and E, are represented by a filled-in circle and will be part of all products that the SPL can generate. Alternative features can be exclusive (XOR) or nonexclusive (OR). XOR (“Alternative”) indicates that only one subfeature can be selected, e.g., F or G; while OR (“Or”) allows more than one option to be selected for a product, e.g., H or I or both H and I. In addition, the diagram includes abstract and concrete features. Feature A, which is abstract, represents an interface; and the rest, which are concrete, are the features that implement the functionalities. FMs can also be specified through textual notations [32].

An interaction design pattern is a design pattern for the field of HCI [33]. It documents proven solutions to interaction design problems in a systematic and understandable way, which is why interaction design patterns are said to be centered on the user. Different formats for interaction design patterns have been proposed [34,35]; these vary in their elements, the number of elements, and the names and order of the elements.

For the domain of iDTV applications, Kunert [8] presents the most complete, richest, and widely accepted collection. This catalog of interactivity design patterns, centered on the DTV user, describes 41 patterns, classified into 10 groups. The catalog provides a template for each pattern that indicates its name, examples, the context of use, the problems it solves, the solutions it provides, citations, and related patterns. The groups and patterns are as follows:

Page Layout Group: Choosing the right page layout, Overlay, Full-screen with video, Full-screen without video

Navigation Group: Multiple ways to navigate, Menu, Video multi-screen, Index, Page numbers, Tabs.

Figure 1 Source. The Authors.

Remote Control Keys Group: Choosing the right keys, Arrow keys, OK-key, Colour keys, Number keys, Special keys.

Basic Functions Group: Initial call to action, Starting, Loading indication, Exiting, Hiding application, Going one level up.

Content Presentation Group: Text design, Content box, Paging, Scrolling, Switching between content items, Synchronized content.

User Participation Group: Multiple ways of user participation, Voting and multiple-choice question, Allocation of items, Text completion, Approval for connectivity.

Text Input Group: Multiple ways to input text, On-screen qwerty or alphabetical keyboard, Mobile phone keyboard.

Help Group: On-screen instruction, Help section.

Accessibility & Personalization Group: Accessibility, Personalization)

Specific User Groups: Children.

All the groups refer to specific types of content and are classified into three classes: tasks of generic users of iDTV, general content requirements, and general usability requirements. We concluded that the concepts in the patterns meet the usability levels required for iDTV, that they can be used effectively, efficiently, safely, and satisfactorily, and that they can be recast as features to provide variability.

This stage defined the scope of the product line as iDTV applications with local interactivity, which involves representing patterns of presentation and selecting additional information. The relevant patterns in the catalog are in the Page Layout, Navigation, Basic Functions, Content, Remote Control Keys, and Help groups, a subset that includes 27 of the 41 patterns in the catalog.

To obtain a first representation, we manually and carefully prepared a feature diagram for 32 iDTV applications using their corresponding patterns. These iDTV applications were taken from [8], and our strategy for defining the hierarchies of the diagrams was to place the iDTV application as the root of the diagram, the groups of patterns at the second level, and the patterns used from each group at the third level. Then we recorded the patterns used by each application in a matrix that grouped the applications into 19 families, in order to identify their similarities and differences.

An initial set of relationships was obtained from this analysis: (1) The Page Layout group is present in all applications. (2) Only one pattern of the Page Layout group (Overlay, Full-screen with video or Full-screen without video) is used in each application. (3) One or more patterns in the Navigation group (Menu, Video Multi-screen, Index, Page Numbers, and/or Tabs) are used in some applications. (4) One or more patterns of the Remote Control group (Arrow, OK, Color, Number, and/or Special) can be selected. (5) One or more patterns of the Basic Functions group (Initial call to action, Starting, Loading indication, Exiting, Hiding application, and/or Going one level up) can be selected. (6) One or more patterns of the Content Presentation group (Text design, Content Box, Paging, Scrolling, Switching between content items, and/or Synchronized content) can be selected. (7) Only one pattern from the Help group (On-screen instruction or help section) is used in an application.

The obtained results allowed us to design the feature diagram shown in Fig. 2, in which the groups of patterns are located at the second level as abstract features and the patterns are represented at the third level as concrete features. The diagram also indicates the classifications corresponding to mandatory, optional, and alternative features.

Figure 2 Source. The Authors.

Next, we added a set of rules to the model. These specify restrictions that must be met by the configurations that are derived from the model for the products (applications). In addition, these rules allow debugging valid products and in turn contribute to the traceability of the created model. The rules are obtained from the same catalog, which defines the relationships between groups of patterns and patterns, and their importance lies in the fact that they allow compliance with the imposed usability guidelines. Because the patterns define complementary and/or exclusionary relationships with other patterns, these guidelines are indicated by rules in the model. Given that they arise at the level of pattern groups, we considered the following initial rules:

Navigation => PageLayout

Remote Control => PageLayout ˄ Navigation

BasicFunction=>PageLayout˄Navigation ˄ RemoteControl

Content => PageLayout ˄ Navigation ˄ RemoteControl

Help => PageLayout ˄ Navigation ˄ RemoteControl

These rules indicate, for example, that to use the patterns of the Remote Control group, patterns of the Page Layout and Navigation group are required, and that to use the patterns of the Basic Functions group, at least one pattern from each of the following groups is required: Page Layout, Navigation, and Remote Control.

Using the presented model, configurations can be derived and valid products can be generated. The configuration of a product is its specification or general instantiation. A configuration of an FM is the result of selecting certain model elements and eliminating others. Through the model presented, a number of configurations or instances of new products can be obtained, such as the following examples:

Product1 = {Overlay, Menu, Color, TextDesign}

Product2={FullWithVideo,Menu,Color,InitialCall,TextDesign}

Product3 = {FullWithoutVideo, Menu, Color, Starting, Loading, Exiting, TextDesign}

The complete FM for iDTV applications, graphically represented, and the corresponding set of rules can be found in this link¹.The diagram incorporates a fourth level of features, which represent the attributes or elements of each pattern. The elements of a pattern can be mandatory, optional, or alternative. Similarly, these new features impose their own restrictions, so that rules to handle them are also incorporated.

Fig. 3 is a cutout of the complete diagram, presenting the graphical representation of the Page Layout group of patterns, which is mandatory and whose specification requires a total of 33 features.

Figure 3 Source. The Authors.

The three patterns of the group (Overlay, Full-screen with video and Full-screen without video) are optional and concrete features. All the elements of these patterns are represented at the fourth level. For example, Overlay consists of two obligatory features, SizeOver (the size of the area that the video occupies on the screen) and TransOver (transparency over the video) that is, whenever Overlay is chosen, the SizeOver and TransOver elements must be specified. SizeOver, in turn, has two options, TotalSize (the video occupies 100% of the screen) or PercSize (the percentage of the screen the video occupies). The latter also offers the options Horizontal or Vertical, which in turn each present three options for the location of the video: Top, Center, or Bottom in the case of Horizontal, and Left, CenterV, or Right in the case of Vertical. TransOver only offers three options, without transparency (NoTrans), Trans30 (30% transparency), or Trans100 (100% transparency).

Thus, the groups of features that are located at the fourth level of the diagram comprise the constituent elements of the patterns, indicating the precise details of the interface. Some patterns do not require more features for their configuration, as is the case with Full-screen without video.

As previously mentioned, the model also includes a set of rules that, when applied to the FM, allow the usability properties specified in the pattern catalog to be met. We defined and applied a set of 50 rules in total for the FM, which can be categorized as rules to control certain features of the same group of patterns and rules to restrict features of different groups of patterns. Examples of rules include:

R#1: TopVideo ˄ LeftVideo ˄ TopMenu => ¬LeftMenu

R#2: LeftVideo ∧ LeftMenu => ¬ LeftCont

R#1 is a restriction that allows placing the video in the upper left while prohibiting placement of the menu in the same position on the screen; this rule is related to the Full-screen with video and Menu patterns, which correspond to different groups. R#2 restricts the position of elements on the screen: if the video and the menu will be on the left side, the content should not be on the left; this rule is related to the Full-screen with video, Menu, and Content patterns. R#1 and R#2 are rules that control the validation of different groups of patterns: R#1 concerns patterns of the Page Layout and Navigation groups, while R#2 concerns patterns of the Page Layout, Navigation, and Content groups.

In summary, to model the 27 interaction design patterns for the design of an SPL, a total of 172 features were required, as detailed in Table 1.

Table 1

Source. The Authors.

The SPL-iDTV tool implements the abstract, generic conceptual model described above. SPL-iDTV was implemented in Java and FeatureIDE [11] with the AHEAD component [12]. This last component allows applying feature-oriented programming [9] techniques. The central idea of the implementation is to modularize iDTV design patterns as features and automatically generate the required sections of code in an NCL document.

The class diagram in Fig. 4 illustrates the most important classes that make up the tool. These classes have been divided into two groups. The classes on the left (App, WinNewProduct, Main, Product, WritelnFile and Connector) are the classes that control and execute the entire process of specifying, configuring, and generating code, regardless of the patterns that are chosen. For example, the App class is the main module that controls all of the execution, offers the functionality of creating a configuration, and allows generating an NCL application, and the Main class realizes the invocation of the classes and methods that implement the patterns involved in a given configuration and controls the entire generation of a final product (the NCL code) through invocation of the WinNewProduct class.

Figure 4 Source. The Authors.

The classes on the right correspond to each of the specific features of the FM and interaction design patterns (Overlay, FullWithVideo, FullWithoutVideo, Menu, VidMultiScreen, Index, PageNumbers, Tabs, Arrow, Ok, Color, Number, Special, InitialCall, Starting, Loading, Exiting, HidingApp, GoingOneLevelUp, TextDesign, ContentBox, Paging, Scrolling, Switching, Synchronized, Instruction, and Section).

The classes that correspond to the concrete features of the FM (patterns and pattern elements) contain all the logic needed to implement a pattern in an NCL document. For this reason, some attributes are concordant with NCL tags, such as region, descriptor, media, and link, which are required in NCL. But each class also specifies its own data for the implementation of the pattern in question.

The SPL-iDTV tool generates an application in three steps:

These three simple steps allow users to automatically generate iDTV applications. The tool is very economical for developing different configurations using the same media until the product that best suits the needs of the TV producer is obtained. Similarly, once the optimal configuration that corresponds to the style of a TV program is found, updating the media is even simpler. The user repeats the task from step 2, that is, updating the media, according to the different broadcasts of a program. This last capability of the tool works as a template generator.

This part of the study consisted in using the SPL-iDTV tool to reproduce three iDTV applications, which were later executed using a Ginga emulator. The case study experimentation had several objectives: to prove the correct functionality of the SPL-iDTV tool, to verify the design of different configurations, to verify that the restrictions that fit the model are correct and flexible, to verify that the generated code is valid, and primarily to verify that the tool can be used to develop applications at the same level of complexity as manually developed application prototypes. For this last reason, the experimentation consisted of replicating manually developed prototypes that make intensive use of the patterns.

The prototypes were extracted from [8]. The Anke Late Night prototype is an entertainment and interview program, produced and issued by the Ilmenau Technology University (Germany) in 2004. The Music prototype is a musical program, also produced and broadcast by the same german university in 2004. The Sport prototype is a sports program, produced and broadcast by the UK’s BBC since 1997.

After the prototypes were selected, the input sets (pattern information and media) necessary for steps 1 and 2 of the development using SPL-iDTV, as indicated in Section 4.2, were determined. Table 2 specifies the input for the Anke Late Night prototype, Table 3 for the Music prototype, and Table 4 for the Sport prototype.

Table 2

Source. The Authors.

Table 3

Table 4

Source. The Authors.

The entries for each case study were entered into SPL-iDTV. Fig. 5 shows the SPL-iDTV configuration interface for the Anke Late Night prototype. The chosen options are highlighted with different shapes: rectangle without corner for the groups of patterns, rectangle for the patterns, and ellipse for the elements of each pattern.

Figure 5 Source. The Authors.

After creating the three configurations and associating the corresponding media, the code for the applications was generated. The applications were then executed in a Ginga emulator. Fig. 6 presents images from these executions.

Figure 6 Source. The Authors.

The reproductions of the prototypes verify that the tool functions correctly, as it was possible to design diverse configurations that include different sets of patterns consisting of various elements and a considerable amount and diversity of medias. The code generated by the tool is correct and executed correctly. The prototypes developed with the tool are not trivial examples, and it was possible to automatically reproduce the manually designed and coded iDTV applications.

To complete the analysis of the prototypes developed in the experimentation, some results are listed in Table 5. The first column indicates the numbers of pattern groups, patterns, concrete and terminal features, and rules represented by the model and implemented by SPL-iDTV. The last three columns indicate the quantities for each prototype. The bottom two rows indicate the amount of media (images, videos, texts) and the number of automatically generated lines of code (LOC) for each prototype.

Table 5

Source. The Authors.

We conducted an evaluation of the quality of the SPL developed with SPL-iDTV, using the method proposed in [13]. This method is based on the quality standard SQuaRE. The main advantage of this method is that it is general and can be applied to any developed SPL. In addition, it is flexible insofar as it allows the independent evaluation of activities at any stage of the SPL development. Although the quality assessment process always involves the same activities at each stage of the SPL’s life cycle, these should be adapted for the conditions of each phase.

In this study, we applied this method to evaluate the maintainability of the SPL. A high degree of maintainability indicates that a product is structured in a way that makes it is easy to modify. This property is one of the most evaluated properties for SPLs, since it considers their modularity and reusability. Modularity analyzes the active proportion by feature, and reusability employs four metrics to independently mediate commonality and variability. Commonality is evaluated by taking into account aspects related to the reuse of assets, because these are common parts of different products, and variability is evaluated based on the SPL’s richness and complexity. The attributes and metrics for commonality involve functional commonality, the functional coverage of an asset, and its cumulative applicability. The attributes and metrics for variability include the variability in an asset and the complexity of the variability of the SPL, captured by measuring the number of variabilities in the SPL.

The results of the evaluation are presented in Table 6. This table also provides the formulas used for the calculations, the acceptable values, the bases, the derived metrics, and the dependencies between them. The possible values of the metrics are continuous values between 0 and 1. Since these are subjective values, we consider each evaluated attribute as accepted or not accepted for an independent reason. The values for the calculation of the metrics were taken from the statistics provided by FeatureIDE.

Table 6

Source. The Authors.

The FM defined for the creation of the proposed SPL presents an acceptable degree of maintainability. Each asset is defined by a feature, which facilitates the modularity of the model. The level of reuse of an asset covered by the functional features of the model does not reach the average possible value, while the coverage of variability is favorable. The predominance of optional and alternative features (variability) controls this tension, giving the model a high level of flexibility.