Cores assets development in software product lines - towards a practical approach for the mobile game domain

Texto

(1)Pós-Graduação em Ciência da Computação. Core Assets Development in Software Product Lines - Towards a Practical Approach for the Mobile Game Domain by. Leandro Marques do Nascimento M.Sc. Dissertation. Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao. RECIFE, AUGUST/2008.

(2) UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS‐GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO . LEANDRO MARQUES DO NASCIMENTO . “CORE ASSETS DEVELOPMENT IN SOFTWARE PRODUCT LINES ‐ TOWARDS A PRACTICAL APPROACH FOR THE MOBILE GAME DOMAIN" ESTE TRABALHO FOI APRESENTADO À PÓSGRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO FINAL PARA OBTENÇÃO DO TÍTULO DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.. ORIENTADOR: SILVIO ROMERO DE LEMOS MEIRA CO-ORIENTADOR: EDUARDO SANTANA DE ALMEIDA. RECIFE, AGOSTO/2008.

(3) Nascimento, Leandro Marques do Cores assets development in software product lines - towards a practical approach for the mobile game domain / Leandro Marques do Nascimento. – Recife: O Autor, 2008. xiii, 128 folhas : il., fig. Dissertação (mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, 2008. Inclui bibliografia e glossário. 1. Ciência da computação. software. I. Título. 004. CDD (22.ed.). 2. Engenharia de. MEI2008-096.

(4) “The journey of a thousand miles begins with a single step.” Lao Tzu.

(5)

(6) A. cknowledgements. One of the most encouraging phrases I have listened from Silvio Meira says: “Nothing beats hard work”. This phrase translates all my feeling at the right moment I finished this work and I may have no words to describe my gratitude to all the people that helped me during this journey. Unfortunately, someone may be forgotten and, for those not listed here, I humbly ask for their apologies and understanding that it was not caused intentionally, but due to tricks played by memory. Initially, I would like to warmly thank my family, specially my parents and my lovely fiancée. Without their caress, attention and incentive, I would not have reached this point. Additionally, I would like to thank my friend and co-advisor Eduardo Almeida for helping me out with all my questions and guiding me through this work. He, in agreement with Silvio Meira, was the one who most encouraged me to apply for the M.Sc. program at Federal University of Pernambuco. Next, I would not forget to thank all the members of the Reuse in Software Engineering (RiSE) group. From the beginning until the very ending of this work, they have been very supportive, sharing their knowledge and fomenting discussions that helped me a lot with all the content of this dissertation. This work was partially funded by Recife Center for Advanced Studies and Systems – C.E.S.A.R, which offered me a great environment to work, learn and practice my knowledge in software reuse area. Besides, this work has been possible thanks to Meantime Mobile Creations, which provided me all the artifacts used in the experimental study performed in this dissertation. Special.

(7) iv thanks to Tarcísio Câmara, from Meantime Mobile Creations, who gave me precious information about mobile games development in practice. My personal gratitude to all the fellows at C.E.S.A.R, especially the Motorola iDEN team. Working with them is an enjoyable everyday activity. Moreover, I would like to thank some key researchers in the software reuse area, Bill Frakes, Dirk Muthig and Jan Bosch, for spending a bit of their time in Brazil to take a look at my work and contribute with valuable feedback. During my final presentation of this work, I received valuable feedback from the reviewers André Santos and Uirá Kulesza, and from my advisor Silvio Meira. Thank you all for dedicating your attention to review this work and providing great comments with interesting discussions. Thanks to the old school friends for being so present and providing me moments of joy and happiness. These moments have been so important to renew my disposition to keep working. My parties, summers, jokes and talks would not have been so funny without them. And last but not least, I want to thank God for giving me strength and illuminating my entire path to the end of this dissertation.. Leandro Marques do Nascimento Recife, Pernambuco, Brazil August 25, 2008.

(8) A. bstract. The most aimed objectives in software engineering are basically high productivity, with high quality at low costs and one possible way for achieving these objectives is establishing software reuse – the process of creating software systems from existing software rather than building them from scratch. In this context, one approach that can enable software reuse in practice is Software Product Line (SPL) – a set of software-intensive systems sharing a common, managed set of features that are developed from a common set of reusable core assets in a prescribed way. A particular domain where the adoption of such approach may bring relevant benefits is the mobile game domain mainly because the games need to run in a big diversity of handsets and there is a big number of games of the same type being developed with common features. However, the characteristics of the mobile game domain usually create barriers to apply SPL processes in practice, such as, restrictions of memory and application size and different API implementations by different manufacturers. In addition, the current SPL processes still lack of details on the phases related to core assets implementation, making it difficult to properly handle the mentioned characteristics of the domain in question. Thus, this work aims at defining a practical approach for implementing core assets in a SPL applied to the mobile game domain based on the good practices from the state-of-the-art in the area. Moreover, in order to evaluate the approach, an experimental study is performed using three platform-based mobile games to build a SPL and, finally, a fourth game is derived from the SPL. Keywords: software reuse, software product line, core assets implementation, mobile game, experimental study..

(9) R. esumo. Os mais almejados objetivos da engenharia de software são basicamente alta produtividade, com alta qualidade a um baixo custo e uma possível forma de atingi-los é estabelecer reuso de software – o processo de criar sistemas de software a partir de sistemas existentes ao invés de criar do início. Neste contexto, uma abordagem que pode habilitar reuso na prática é Linha de Produto de Software (LPS) – um conjunto de sistemas de software que compartilham um conjunto comum e gerenciado de funcionalidades que satisfazem uma necessidade específica de um domínio, e que são desenvolvidas a partir de um conjunto de artefatos reusáveis. Um domínio em particular onde a adoção de tal abordagem pode trazer benefícios é o domínio de jogos móveis principalmente porque os jogos precisam executar em diversos dispositivos e existe uma grande quantidade de jogos do mesmo tipo sendo desenvolvidos com funcionalidades em comum. Entretanto, as características do domínio de jogos móveis geralmente criam barreiras para os processos de LPS na prática, tais como, restrições de memória e de tamanho da aplicação e diferentes implementações de API feitas por diferentes fabricantes. Além disso, os atuais processos de LPS ainda carecem de detalhes em fases relacionadas à implementação de artefatos reusáveis, dificultando a administração apropriada das características mencionadas. Dessa forma, este trabalho objetiva definir uma abordagem prática para implementação de artefatos reusáveis em uma LPS para o domínio de jogos móveis com base nas boas práticas do estado da arte na área. Além disso, com a intenção de avaliar a abordagem, um estudo experimental foi executado com três jogos de plataforma para construir a LPS e um quarto jogo foi derivado dela. Palavras-chave: reuso de software, linha de produto de software, implementação de artefatos reusáveis, jogos móveis, estudo experimental..

(10) T. able of Contents. ACKNOWLEDGEMENTS ............................................................... III RESUMO ......................................................................................... V ABSTRACT .....................................................................................VI TABLE OF CONTENTS .................................................................. VII LIST OF FIGURES............................................................................X LIST OF TABLES............................................................................ XI LIST OF ACRONYMS .................................................................... XII 1. INTRODUCTION ..........................................................................1 1.1. 1.2. 1.3. 1.4. 1.5.. MOTIVATION ..............................................................................................3 PROBLEM STATEMENT................................................................................. 5 OVERVIEW OF THE PROPOSED SOLUTION .....................................................6 OUT OF SCOPE ............................................................................................ 7 ORGANIZATION OF THE DISSERTATION ........................................................8. 2. SOFTWARE PRODUCT LINE CONCEPTS .................................... 9 2.1. SOFTWARE REUSE ..................................................................................... 10 2.2. SOFTWARE PRODUCT LINES (SPLS)........................................................... 12 2.2.1. What Software Product Lines are not............................................ 14 2.2.1.1. Fortuitous Small-Grained Reuse........................................... 14 2.2.1.2. Single System Development with Reuse ............................... 14 2.2.1.3. Just Component-Based Development................................... 15 2.2.1.4. Just a Reconfigurable Architecture ....................................... 15 2.2.1.5. Releases and Versions of Single Products............................. 15 2.2.1.6. Just a Set of Technical Standards.......................................... 16 2.3. BENEFITS OF SOFTWARE PRODUCT LINES .................................................. 16 2.3.1. Enhancement of Quality ................................................................ 16 2.3.2. Reduction of Maintenance Effort .................................................. 16 2.3.3. Reduction of Development Costs................................................... 17 2.3.4. Reduction of Time to Market......................................................... 17 2.3.5. Improving Cost Estimation............................................................ 18 2.3.6. Benefits for the Customers............................................................. 18 2.4. MATURITY AND EVOLUTION IN SOFTWARE PRODUCT LINES ........................ 19.

(11) viii 2.5. SUCCESSFUL CASES IN SOFTWARE PRODUCT LINES .................................... 21 2.5.1. Philips.............................................................................................22 2.5.2. Hewlett-Packard (HP) ...................................................................23 2.5.3. Boeing.............................................................................................24 2.5.4. Nokia ..............................................................................................24 2.6. CHAPTER SUMMARY ..................................................................................26 3. SOFTWARE PRODUCT LINE PROCESSES: A SURVEY...............27 3.1. COMPONENT-BASED DEVELOPMENT (CBD)...............................................28 3.1.1. Catalysis .........................................................................................28 3.1.2. UML Components..........................................................................29 3.2. DOMAIN ENGINEERING PROCESSES ........................................................... 31 3.3. SOFTWARE PRODUCT LINE PROCESSES ......................................................34 3.3.1. GenVoca and Object-Oriented Product Lines and Frameworks...35 3.3.2. Product Line Software Engineering (PuLSETM) ............................ 37 3.3.3. Family-Oriented Abstraction, Specification and Translation (FAST) ............................................................................................39 3.3.4. The KobrA Approach .................................................................... 40 3.3.5. Component-Oriented Platform Architecting Method (CoPAM)...42 3.3.6. Software Product Lines by SEI ......................................................43 3.3.7. FORM’s Extension .........................................................................44 3.3.8. Product Line UML-Based Software Engineering (PLUS) ..............45 3.3.9. Software Product Line Engineering (SPLE) Framework ..............46 3.4. SUMMARY OF THE STUDY........................................................................... 47 3.5. CHAPTER SUMMARY ..................................................................................50 4. CORE ASSETS DEVELOPMENT IN SOFTWARE PRODUCT LINES - TOWARDS A PRACTICAL APPROACH FOR THE MOBILE GAME DOMAIN......................................................................................... 51 4.1. INTRODUCTION .........................................................................................52 4.2. CORE ASSETS DEVELOPMENT IN SOFTWARE PRODUCT LINES - TOWARDS A PRACTICAL APPROACH FOR THE MOBILE GAME DOMAIN ............................54 4.2.1. Component Modeling ....................................................................59 4.2.2. Component Implementation .........................................................63 4.2.3. Component Testing........................................................................78 4.4. CHAPTER SUMMARY .................................................................................. 79 5. AN EXPERIMENTAL STUDY IN THE MOBILE GAME DOMAIN .... ..................................................................................................81 5.1. INTRODUCTION .........................................................................................82 5.2. THE EXPERIMENTAL STUDY ......................................................................84 5.2.1. The Definition ................................................................................84 5.2.1.1. Goal ........................................................................................84 5.2.1.2. Questions ...............................................................................85 5.2.1.3. Metrics ...................................................................................85 5.2.2. The Planning ..................................................................................87 5.2.3. The Project Used in the Study ...................................................... 90 5.2.4. The Instrumentation......................................................................92 5.2.5. The Operation ................................................................................92 5.2.6. The Analysis and Interpretation.................................................. 101.

(12) ix 5.2.7. Conclusions .................................................................................. 103 5.2.8. The Lessons Learned ................................................................... 104 5.3. CHAPTER SUMMARY ................................................................................ 105. 6. CONCLUSIONS ........................................................................106 6.1. 6.2. 6.3. 6.4. 6.5.. RESEARCH CONTRIBUTIONS .................................................................... 107 RELATED WORK......................................................................................108 FUTURE WORK ....................................................................................... 110 ACADEMIC CONTRIBUTIONS ..................................................................... 111 CONCLUDING REMARKS ...........................................................................113. REFERENCES............................................................................... 114.

(13) L. ist of Figures. FIGURE 1.1. THE RISE FRAMEWORK FOR SOFTWARE REUSE. ......................................4 FIGURE 2.1. COSTS FOR DEVELOPING N KINDS OF SYSTEMS AS SINGLE SYSTEMS COMPARED TO PRODUCT LINE ENGINEERING ....................................................... 17 FIGURE 2.2. TIME TO MARKET WITH AND WITHOUT PRODUCT LINE ENGINEERING. .... 18 FIGURE 2.3. MATURITY LEVELS FOR SOFTWARE PRODUCT LINES ............................... 19 FIGURE 3.1. CREATING INHERITANCE HIERARCHIES BY COMPOSING LAYERS..............36 FIGURE 3.2. REFINEMENTS HIERARCHIES AND FRAMEWORK INSTANCES ................... 37 FIGURE 3.3. PULSETM OVERVIEW...........................................................................38 FIGURE 3.4. KOMPONENT SPECIFICATION AND REALIZATION MODELS ....................... 41 FIGURE 3.5. PRODUCTS, METHODS AND FAMILIES ....................................................42 FIGURE 3.6. THREE ESSENTIAL ACTIVITIES ..............................................................44 FIGURE 3.7. DOMAIN ENGINEERING AND PRODUCT LINE PROCESSES TIMELINE. ........48 FIGURE 4.1. APPROACH OVERVIEW OF SPL DOMAIN IMPLEMENTATION STEP APPLIED TO THE MOBILE DOMAIN. ................................................................................... 55 FIGURE 4.2. EXAMPLE OF THE DOMAIN ARCHITECTURE FOR THE MOBILE GAME DOMAIN. ...........................................................................................................58 FIGURE 4.3. EXAMPLE OF INTERNAL COMPONENT DESIGN (STRUCTURAL MODEL) WITH THE USE OF VARIANT STEREOTYPE. .....................................................................62 FIGURE 4.4. EXAMPLE OF COMPONENT INTERNAL DESIGN WITH ADDITIONAL INFORMATION OF THE APPLICABLE CONDITIONAL COMPILATION TAGS ..................63 FIGURE 5.1. GQM HIERARCHICAL MODEL (BASILI ET AL., 1994)..............................83 FIGURE 5.2. SCREENSHOTS OF THE GAMES USED FOR THE EXPERIMENTAL STUDY. A) MONGA. B) AMERICAN DAD – ROGER’S SCAPE. C) ZAAK..................................... 91 FIGURE 5.3. DOMAIN FEATURE MODEL. ...................................................................94 FIGURE 5.4. INTERNAL DESIGN OF THE ENEMY (AI) COMPONENT. ............................ 97 FIGURE 5.5. SMART ESCAPE APPLICATION FEATURE MODEL BASED ON THE DOMAIN FEATURE MODEL..............................................................................................100 FIGURE 5.6. SMART ESCAPE’S MAIN GAME SCREEN.................................................100 FIGURE 6.1. ABSTRACTION LEVELS IN SOFTWARE PRODUCT LINES APPLIED TO MOBILE GAME DOMAIN................................................................................................. 109.

(14) L. ist of Tables. TABLE 4.1. EXAMPLE OF PRODUCT PORTFOLIO WITH PRIORITIES AMONG FAMILIES OF HANDSETS .........................................................................................................56 TABLE 4.2. EXAMPLE OF PRODUCT MAP ................................................................. 57 TABLE 4.3. EXAMPLE OF MAPPING OF HANDSET FAMILIES AND THEIR MAIN CAPABILITIES IN THE PRODUCT MAP ....................................................................58 TABLE 4.4. EXAMPLE OF PRODUCT MAP WITH CONDITIONAL COMPILATION TAGS ATTACHED ......................................................................................................... 61 TABLE 4.5. EXAMPLE OF MAPPING OF HANDSET FAMILIES, THEIR MAIN CAPABILITIES AND THE RESPECTIVE CONDITIONAL COMPILATION TAGS ..................................... 61 TABLE 4.6. EXAMPLE OF COMPONENT DOCUMENTATION AFTER ITS IMPLEMENTATION.. ...........................................................................................78 TABLE 4.7. SUMMARY OF THE APPROACH FOR CORE ASSETS DEVELOPMENT IN A SPL APPLIED TO THE MOBILE GAME DOMAIN ............................................................. 80 TABLE 5.1. PRODUCT PORTFOLIO WITH THREE MANUFACTURERS LISTED.................95 TABLE 5.2. PRODUCT MAP WITH CONDITIONAL COMPILATION TAGS ATTACHED. .......96 TABLE 5.3. GROUPS OF CONDITIONAL COMPILATIONS TAGS FOR THE FOUR MANUFACTURERS DESCRIBED IN PRODUCT PORTFOLIO ........................................96 TABLE 5.4. BASIC DOMAIN ARCHITECTURE OVERVIEW ..........................................100 TABLE 5.5. COMPONENTS OVERVIEW. .................................................................. 101 TABLE 5.6. COMPONENT COMPLEXITY VALUES ..................................................... 101 TABLE 5.7. DOMAIN RESTRICTIONS MANAGEMENT VALUES ................................... 102 TABLE 5.8. TRACEABILITY VALUES ....................................................................... 103.

(15) L. ist of Acronyms. ADL – ARCHITECTURE DESCRIPTION LANGUAGE.....................................................39 AI – ARTIFICIAL INTELLIGENCE .............................................................................. 97 AML – APPLICATION MODELING LANGUAGE .......................................................... 40 AOP – ASPECT-ORIENTED PROGRAMMING ............................................................. 60 API – APPLICATION PROGRAMMING INTERFACE ........................................................ 5 CBD – COMPONENT-BASED DEVELOPMENT .............................................................. 1 CBSE – COMPONENT-BASED SOFTWARE ENGINEERING.............................................6 CDC – CONNECTED DEVICE CONFIGURATION .......................................................... 77 CLDC – CONNECTED LIMITED DEVICE CONFIGURATION..........................................64 COPAM – COMPONENT-ORIENTED PLATFORM ARCHITECTING METHOD .................42 DE – DOMAIN ENGINEERING ....................................................................................9 DLL – DYNAMIC LINK LIBRARIES............................................................................64 DSL – DOMAIN-SPECIFIC LANGUAGE ........................................................................ 1 DSSA – DOMAIN-SPECIFIC SOFTWARE ARCHITECTURE ...........................................38 FAST – FAMILY-ORIENTED ABSTRACTION, SPECIFICATION AND TRANSLATION .........39 FODA – FEATURE ORIENTED DOMAIN ANALYSIS ....................................................32 FORM – FEATURE-ORIENTED REUSE METHOD ...................................................... 31 GQM – GOAL QUESTION METRIC ...........................................................................82 GSM – GLOBAL SYSTEM FOR MOBILE COMMUNICATIONS ...........................................3 HTTP – HYPERTEXT TRANSFER PROTOCOL ..............................................................2 IRS – INERTIAL REFERENCE SYSTEM ...................................................................... 21 JAR – JAVA ARCHIVE .............................................................................................56 JME – JAVA MICRO EDITION....................................................................................3 JSE – JAVA STANDARD EDITION ............................................................................. 77 JSR – JAVA SPECIFICATION REQUEST .....................................................................53 KOBRA – KOMPONENTENBASIERTE ANWENDUNGSENTWICKLUNG .............................. 7 MIDP – MOBILE INFORMATION DEVICE PROFILE ....................................................56 OCL – OBJECT CONSTRAINT LANGUAGE..................................................................30 ODM – ORGANIZATION DOMAIN MODELING........................................................... 31 OFP – OPERATIONAL FLIGHT PROGRAM .................................................................24 OO – OBJECT ORIENTATION ...................................................................................35 OSGI – OPEN SERVICES GATEWAY INITIATIVE .........................................................33 PDA – PERSONAL DIGITAL ASSISTANT ....................................................................64 PLUS –PRODUCT LINE UML-BASED SOFTWARE ENGINEERING ................................45 PULSE – PRODUCT LINE SOFTWARE ENGINEERING ................................................... 7 RIDE – RISE PROCESS FOR DOMAIN ENGINEERING ................................................. 31 RISE – REUSE IN SOFTWARE ENGINEERING ..............................................................4 RSEB - REUSE-DRIVEN SOFTWARE ENGINEERING BUSINESS.................................... 31.

(16) xiii RUP – RATIONAL UNIFIED PROCESS .......................................................................29 SEI – SOFTWARE ENGINEERING INSTITUTE ............................................................. 21 SPL – SOFTWARE PRODUCT LINE .............................................................................. 1 SPLE – SOFTWARE PRODUCT LINE ENGINEERING ...................................................46 UML – UNIFIED MODELING LANGUAGE..................................................................28 USDP – UNIFIED SOFTWARE DEVELOPMENT PROCESS ............................................45 XP – EXTREME PROGRAMMING ..............................................................................54.

(17) 1. Introduction. “No great discovery was ever made without a bold guess” Isaac Newton (1642 – 1726) English physicist and mathematician. One of the key factors for improving quality, productivity and consequently reducing costs in software development is the adoption of software reuse – the process of creating software systems from existing software rather than building them from scratch (Krueger, 1992). Several research activities have been performed in the software reuse area (Almeida et al., 2007a) involving different aspects, such as: different techniques of programming, for example, generative programming (Czarnecki & Eisenecker, 2000) and Domain-Specific Languages (DSL) (Greenfield et al., 2004), which can make possible to automate code generation; Component-Based Development (CBD) methods (Cheesman & Daniels, 2001), (D'Souza & Wills, 2001), (Szyperski, 2002), which explore the benefits of reusing software components; and reuse processes, considering a systematic sequence of activities to enable the development for and with reuse (Weiss & Lai, 1999), (Bayer et al., 1999), (Atkinson et al., 2000), (Clements & Northrop, 2001), (Gomaa, 2005), (Pohl et al., 2005), (Almeida, 2007). Besides, different efforts have been made to apply the concepts of this area in practice with successful cases (SPL Hall of Fame, 2008), including big companies such as Hewlett-Packard (HP), Bosch and Nokia. An approach commonly cited in the software reuse area is Software Product Line (SPL), which can be defined as “a set of software-intensive.

(18) Chapter 1 – Introduction. 2. systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way” (Clements & Northrop, 2001). In other words, a SPL allows new applications to be instantiated based on a set of core assets, developed from the analysis of the commonalities and variabilities of a specific domain or market segment. Furthermore, a particular market segment that is in high-growth during the last years is the mobile applications market, especially the mobile games. According to iSuppli 1 , the prediction is that the worldwide mobile gaming market will be worth $6.1 billion in 2010 – up from $1.8 billion in 2005. However, this market involves much more complex challenges, mainly because of the variety of handsets and manufacturers, many platform restrictions and different hardware configurations. For example, a game produced by Meantime 2 , called My Big Brother, had to be deployed for almost fifty devices and the game had to support variations across those devices, such as: different screen sizes, different ways of handling HTTP protocol and different keypad configurations (Alves et al., 2005a). This scenario demands well defined software processes to build applications compatible with as many handsets as possible, considering the variabilities across handset platforms and possible commonalities among various games in the same domain. Therefore, SPL can be a suitable option in this case. Different works have been published in the SPL area describing general purpose processes applied to different contexts, from avionics (Sharp, 2000) to consumer electronics (Ommering, 2002). However, considering the lack of details of those processes in the core assets implementation phase, they can not address properly the early mentioned restrictions of the mobile game domain. Thus, the establishment of a SPL approach capable of handling those restrictions is the main subject of this work. This chapter contextualizes the focus of this work and starts by presenting its motivation with a clear definition of the problem.. 1. iSuppli Corporation: Applied Market Intelligence, available on http://www.isuppli.com/, accessed in January, 2008. 2 Meantime Mobile creations, available on http://www.meantime.com.br, accessed in January, 2008..

(19) Chapter 1 – Introduction. 3. 1.1. Motivation Software reuse is generally regarded as the most important mechanism for performing software development more efficiently (Krueger, 1992). The ideas behind software reuse started to come up in the late 1960s, when McIlroy (1968), motivated by the software crisis, wrote the so referenced paper on software reuse entitled “Mass Produced Software Components”. Since that time, many discussions took place, involving issues ranging from the possibility of a software industrial revolution (Cox, 1990), in which programmers would stop coding everything from scratch and begin assembling applications from well-stocked catalogs of reusable software components, until silver bullets (Moore, 2001) based on software reuse. Several works have discussed the benefits of software reuse in terms of improvements on productivity and software quality, and reduction on costs (Lim, 1994), (Mili et al., 1995), (Basili et al., 1996), (Sametinger, 1997), (Frakes & Succi, 2001), (Ezran et al., 2002), (Poulin, 2006). In addition, many successful industrial cases of software reuse, specifically SPL (SPL Hall of Fame, 2008), involving, for example, Philips, Boeing, Nokia, Hewlett-Packard (HP), General Motors, can indicate that those benefits are reachable. On the other hand, one of the greatest motivations for this work is related to the mobile domain. A picture of the mobile global market in 2008 reveals that the number of mobile phones is about three billions, according to GSM World 3 , and it is rapidly growing. This is only considering the GSM technology and means that almost half the world population may possess a mobile phone. Among these phones, Sun Microsystems 4 estimates that at least half a billion of them are Java-enabled. This last data shows that Java Micro Edition (JME) (Java ME, 2008) is the most ubiquitous platform present in the mobile phones. Immersed in this huge Java mobile world are the mobile games, which can be considered the fastest growing “new” games sector, considering the prediction that mobile gaming will be worth $6.1 billion by the end of this decade. So, bringing SPL approach into the mobile game domain can improve productivity. 3. GSM World - the website of the GSM Association, available on http://www.gsmworld.com/, accessed in January, 2008. 4 Sun Microsystems, available on http://www.sun.com/, accessed in January, 2008..

(20) Chapter 1 – Introduction. 4. and reduce costs in a promising area, possibly drawing attention of academia and achieving good results in practice. Besides those motivations, it is important to highlight that this work is part of the Reuse in Software Engineering (RiSE) project 5 (Almeida et al., 2004), whose goal is to develop a robust framework for software reuse in order to enable the adoption of a reuse program. The proposed framework has two layers, as shows Figure 1.1. The first layer (on the left side) is formed by good practices related to software reuse. Non-technical aspects, such as education, training,. incentives,. program. to. introduce. reuse,. and. organizational. management are considered. This layer constitutes a fundamental step before the introduction of the framework in organizations. The second layer (on the right side), is formed by important technical aspects related to software reuse, such as processes, environment, and tools. This work is part of RiSE framework in the second layer, specifically in the area of Software Reuse Process.. Figure 1.1. The RiSE framework for software reuse. As can be seen in Figure 1.1, the RiSE project addresses reuse aspects not included in the scope of this thesis, such as component search (Martins et al., 2008), component testing (Silva et al., 2008), SPL architecture (Filho et al., 2008) and SPL cost models (Nobrega et al., 2008), besides other aspects covered by the project including reuse adoption strategies (Garcia et al., 2008a) and assessment methods for software reuse capability (Garcia et al., 2008b).. 5. The RiSE project in the web, available on http://www.rise.com.br, accessed in May, 2008..

(21) Chapter 1 – Introduction. 5. 1.2. Problem Statement As stated by (Ezran et al., 2002), a process can be understood as a collection of related tasks leading to a product. Another point of view describes simply a software process as a way of defining specifically who does what, when, and how (Fayad, 1997). In addition, a process is important to define how an organization is supposed to perform its activities, and how people work and interact, in order to ensure efficiency, reproducibility, and homogeneity (Ezran et al., 2002). Different works discuss the benefits and improvements of using a well-defined software process (Basili et al., 1995), (McConnell, 1998). Specifically in the SPL area, different processes have been established in order to systematically define the set of activities, steps, roles, inputs and outputs within a SPL and then make possible the practical application of SPL principles (Chapter 3 provides detailed discussions about those SPL processes). In general, the SPL process can be divided in two distinct phases: core assets development (or domain engineering) and product development (or application engineering). During the first phase, the domain is analyzed taking into consideration the possible existent applications, a reference architecture (or domain architecture) is designed with the commonalities and variabilities in domain, and then the core assets are implemented. In the second phase, the reference architecture is instantiated and the already developed artifacts are reused to create new applications. Throughout these two phases, management is necessary to ensure the correct creation and usage of core assets (Clements & Northrop, 2001). Generally observing the relevant works in SPL processes area, it was noticed that there is still a lack of details in the steps related to core assets implementation (or domain implementation), such as: how domain features can be mapped on components and correspondingly on code; how variability can be managed in code level; which guidelines should be used to apply variability implementation techniques. The lack of details in domain implementation phases can make SPL approach unaffordable especially when it is taken into account the restrictions of mobile game domain, such as memory size, processing power, different screen sizes and different API implementations..

(22) Chapter 1 – Introduction. 6. Because of these characteristics involving the mentioned domain, the adoption of a SPL should be supported by as many details as possible at code level. Therefore, the main goal of this work can be stated as: This work defines a practical approach for implementing core assets in software product lines applied to the mobile game domain (Java Micro Edition). Furthermore, it details the steps of domain implementation, describing a set of activities, inputs, outputs, guidelines and roles. Moreover, the work is based on the good practices from the state-of-the-art in the area.. 1.3. Overview of the Proposed Solution The practical approach for implementing core assets in software product lines applied to the mobile game domain, mentioned in the last section, is based on the following principles (in Chapter 4, the approach is discussed in details): •. Component-Based Development. The approach presents the characteristics of the Component-Based Software Engineering (CBSE) process model (Pressman, 2005), since reusable assets are used to develop applications.. •. Iterative and Incremental. The approach is iterative and incremental, since it is important to divide the effort in iterations and increments in order to more easily manage the activities.. •. Domain-Specific Driven. The approach proposed by this work is particularly tailored to be used in the mobile game domain. Besides these principles, the approach focuses on core assets. implementation and is composed of three phases: component modeling, component implementation, and component testing. In summary, component modeling phase specifies the components’ internal design considering the families of devices; component implementation uses a set of guidelines to implement the specified components considering scenarios of the mobile game domain; and, finally, component testing aims at documenting domain test cases.

(23) Chapter 1 – Introduction. 7. and application-specific test cases, describing some guidelines on how to test components in the mobile domain.. 1.4. Out of Scope As the proposed approach of this work is part of a broader context, a set of related aspects will be left out of its scope. The following issues are not directly addressed by this work: •. Domain Analysis. In the description of this work, the domain analysis phase is not considered in details. The good practices from other processes were taken for this work as they reasonably attend to the need of documenting and designing domain features. Moreover, there is another work at RiSE group aiming directly at the issues related to domain analysis phase (Lisboa et al., 2007).. •. Domain Architecture. For the same reasons of domain analysis, the domain architecture establishment is not detailed. The good practices from PuLSE (Bayer et al., 1999) and KobrA (Atkinson et al., 2000) processes (detailed in Chapter 3) attend the need of defining common and variable points within the domain architecture.. •. Component Identification. Identifying components in domain architecture involves many other issues that do not belong to the scope of this work. There are relevant researches in this area such as: (Kang et al., 1998), (Almeida, 2007) and (Kim & Chang, 2004). Using techniques for automatically identifying components in domain architecture can aid domain architect when there is no domain expert present or the architecture reaches a high level of complexity.. •. Economics. Business aspects are an important instrument to aid managers to start a software product line effort, since it can show the return on investment in a specific domain. Nevertheless, it is not a trivial issue. There is a specific work at RiSE group addressing economic aspects of SPLs (Nobrega et al., 2008).. •. Product Derivation. Once the SPL architecture is defined and the core assets are implemented, the next step is to derive products by reusing this.

(24) Chapter 1 – Introduction. 8. infrastructure (Pohl et al., 2005). This work does not provide many details about product derivation steps, mainly because, at this point, some tools can be used to aid on automatically deploying new products from the SPL by choosing the domain features, such as FLiP (Calheiros et al., 2007).. 1.5. Organization of the Dissertation This document is organized as follows. Chapter 2 presents a comprehensive history of software reuse with its fundamentals and describes the basic concepts behind software product lines. Examples of successful cases involving big companies which have adopted software product lines are also provided. Chapter 3 reviews nine relevant software product line processes and mentions seven domain engineering processes, representing the state-of-the-art in the area. The foundations, elements, and steps of the software product line processes are also shown, depicting their strong and weak points. Chapter 4 proposes a practical approach for implementing cores assets in a software product line applied to the mobile game domain. The approach is based on the good practices from other processes and on industrial experience, taking into consideration the restrictions of the mobile domain, such as memory size, processing power and limited application size. Chapter 5 describes an experimental study in order to evaluate the proposed approach. During the execution of the study, three different platformbased mobile games are analyzed and an initial software product line is established using the proposed approach. In addition, a fourth game is derived from this SPL. Chapter 6 is the last chapter in this dissertation. It summarizes the contributions of this work, presents the related work and shows the directions for future work..

(25) 2. Software Product Line Concepts. “Your theory is crazy, but it may not be crazy enough to be true” Niels Bohr (1885 – 1962) Nobel Prize in Physics (1922), Danish theoretical physicist. A simple yet meaningful definition of software reuse is given by (Krueger, 1992): “Software reuse is the process of creating software systems from existing software rather than building software systems from scratch”. This definition may seem easy to be implemented in practice, however software reuse has for some times failed to become a standard software engineering practice (Krueger, 1992). Several approaches have been developed trying to make software reuse feasible, such as: Component-Based Development (CBD) (D'Souza & Wills, 2001), (Cheesman & Daniels, 2001), (Almeida et al., 2007a), Domain Engineering (DE) (Jacobson et al., 1997), (Villela, 2000), (Almeida, 2007b) and Software Product Lines (SPLs) (Bayer et al., 1999), (Weiss & Lai, 1999), (Clements & Northrop, 2001). Among the cited approaches, software product lines have received considerable adoption in the software industry and have proved to be a very successful approach to intra-organizational software reuse (Bosch, 2002). In this context, this chapter shows the basic concepts and ideas involved with software product lines..

(26) Chapter 2 – Software Product Line Concepts. 10. In order to cover the basic software product line concepts, we briefly discuss the concepts of software reuse and software components in Section 2.1. Next, in Section 2.2, we present the definitions of a SPL and show examples of what SPLs are not. The benefits of using the SPL approach are commented in the Section 2.3. To help on understating the evolution path of an organization which decides to adopt SPL, Section 2.4 describes the possible maturity levels applied to a SPL, and, in the sequence, Section 2.5 brings four successful cases. Finally, Section 2.6 presents a summary of this chapter.. 2.1. Software Reuse Software reuse has been a goal in software engineering since 1968 (McIlroy, 1968), when the term software engineering was first coined. McIlroy defended the idea that software components, usually compared to routines, should be available in families arranged according to precision, robustness, generality and performance. These component libraries allow components to be widely applicable to different machines and users. Nowadays, the benefits of using software components are widely known and constructing large systems from small pieces can reduce the development time and improve the final product quality (Szyperski, 2002). Many definitions for a software component can be found in the literature. After almost thirty years of McIlroy’s definition, (Sametinger, 1997) defined: “Reusable software components are self-contained, clearly identifiable artifacts that describe and/or perform specific functions and have clear interfaces, appropriate documentation and a defined reuse status.” Another definition well accepted by academia is from (Aoyama et al., 2001, pp. 7): “A software component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a component standard”. For Aoyama et al., “A component model defines specific interaction and composition standards. A component model implementation is the dedicated set of executable software elements required to support the execution of components that conform to the model”. They also define the software component infrastructure as “a set of interacting software components designed to ensure that a software system or.

(27) Chapter 2 – Software Product Line Concepts. 11. subsystem constructed using those components and interfaces will satisfy clearly defined performance specifications”. One satisfactory definition is presented by (Szyperski, 2002, pp. 41): “A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.” Considering the mentioned definitions, in traditional software reuse, a library of reusable components is developed. This approach requires the establishment of a library of reusable components and of an approach for indexing, locating, and distinguishing among similar components (Prieto-Diaz & Freeman, 1987). Some problems with this approach include managing the large number of components that such a reuse library is likely to contain and distinguishing among similar though not identical components. The reusable component library is composed by the building blocks used to construct the new system. Components are considered to be largely atomic and ideally unchanged when reused, although some adaptations may be required. Depending on the development approach, the library could contain functional or object-oriented components (Nascimento et al., 2006). An example of this traditional reuse is a subroutine library, which consists of a collection of reusable subroutines in a given application area—for example, a mathematical subroutine library. Another example is an objectoriented toolkit, which consists of a set of related and reusable classes designed to provide useful, general-purpose functionality. Apart from certain specific domains, such as mathematical libraries, the benefits of the traditional software reuse approach have been limited in general. With this approach, overall reuse is relatively low, and the emphasis is on code reuse. Instead of reusing an individual component, it is much more advantageous to reuse a whole design or subsystem, consisting of the components and their interconnections (Gomaa, 2005). This means reuse of the control structure of the application, including artifacts of requirements,.

(28) Chapter 2 – Software Product Line Concepts. 12. architecture, code and tests. Thus, the reuse of such artifacts has much greater potential than component reuse because it is large-grained reuse.. 2.2. Software Product Lines (SPLs) According to (Gomaa, 2005): “The most promising approach for architecture reuse is to develop a product line architecture, which explicitly captures the commonality and variability in the family of systems that constitutes the product line”. Different terms are used to refer to a SPL, such as a software product family, a family of systems, or an application domain. Parnas referred to a collection of systems that share common characteristics as a family of systems (Parnas, 1978). According to Parnas, it is worth considering the development of a family of systems when there is more to be gained by analyzing the systems collectively rather than separately — that is, when the systems have more features in common than features that distinguish them. Nowadays, a family of systems is referred to as a Software Product Line (SPL). According to (Clements & Northrop, 2001, pp. 05): “A Software Product Line is a set of software-intensive systems sharing a common, managed set of features, that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way”. This definition puts constraints on the way systems in a SPL are developed, mainly because substantial production economies can be achieved when the systems in a SPL are developed from a common set of assets in a prescribed way, in spite of being developed separately from scratch. Then, these production economies can make SPLs attractive. Other important contribution about SPLs is described by (Pohl et al., 2005), which bring up the domain of automobiles to clarify the concepts. They say that, formerly, goods were handcrafted for individual customers. By and by, the number of people who could afford to buy various types of products increased leading to Ford’s invention of the production line in the domain of automobiles, which enabled production for a mass market much cheaper than individual product creation. However, the production line reduced the possibilities for diversification..

(29) Chapter 2 – Software Product Line Concepts. 13. Roughly, both types of products, individual and mass produced ones, can be identified in the software domain as well: they are denoted as individual software and standard software. Generally, each type of these products has its drawbacks. Individual software products are rather expensive, while standard software products lack sufficient diversification. Once the customers got used to standardized mass products, they started to want some kind of customization. Not all people want the same kind of car for any purpose. For example, there are cars used for travelling by a single person, others for big families. There are some cars that are used by people living in cities, others mainly in the countryside. Thus, industry was confronted with a rising demand for individualized products. This was the beginning of mass customization, which is the large-scale production of goods tailored to individual customers’ needs (Davis, 1987). Combined with the concept of mass customization, (Pohl et al., 2005) introduced the concept of platforms. At the side of the customer, mass customization means the ability to have an individualized product. At the side of the organization, mass customization means higher technological investments which leads to higher prices for the individualized products and/or to lower profit margins. Both effects are undesirable. Thus many organizations, especially in the car industry, started to introduce common platforms for their different types of cars by planning beforehand which parts will be used in different car types. In this context, a platform is any base of technologies on which other technologies or processes are built (Pohl et al., 2005). Combining the concepts of mass customization and common platforms, allows us to reuse a common base of technology and, at the same time, to bring out products in close accordance with customers’ wishes. This systematic combination for the development of software-intensive systems and software products is what can be called software product line engineering (Pohl et al., 2005). In this dissertation, the term software product lines will be used, since it is widely accepted by universities and industry..

(30) Chapter 2 – Software Product Line Concepts. 14. 2.2.1. What Software Product Lines are not For better understanding the definitions of software product lines, Clements & Northrop enumerate some types of software reuse that should not be considered as SPLs.. 2.2.1.1.. Fortuitous Small-Grained Reuse. Past reuse agendas have focused on the reuse of relatively small pieces of code – that is small-grained reuse. Organizations have built reuse libraries containing algorithms, modules, objects, or components. Almost anything a software developer writes goes into the library. Thus, other developers urged to use what the library provides instead of creating their own versions. Unfortunately, it often takes longer to locate these small pieces and integrate into the system than it would take to build them from scratch. Many times, the documentation involved with these small pieces does not explain how to generalize or adapt it to other situations. On the other hand, in a SPL approach, the reuse is planned, enabled, and enforced – the opposite of opportunistic. All the assets are designed to be reused and are optimized for use in more than a single system. The reuse in SPLs is comprehensive and profitable.. 2.2.1.2.. Single System Development with Reuse. A common situation in software engineering is when a team starts the development of a new system and realizes that another system, very similar to the one on development, had already been released. Then, the team borrows what is possible from the previous effort, modifies it as necessary, adds whatever it takes, and fields the new product. It has probably meant economic advantage in comparison to the previous work, mainly because parts of another system have been reused. However, this is ad hoc reuse. There are two major differences between this approach and a software product line approach: first, software product lines reuse assets that were designed explicitly for reuse; and second, the product line is treated as a whole, not as multiple products that are viewed and maintained separately..

(31) Chapter 2 – Software Product Line Concepts. 2.2.1.3.. 15. Just Component-Based Development. Software product lines rely on a form of component-based development, but much more is involved. The typical definition of component-based development involves the selection of components from an in-house library or the marketplace to build products. Although the products in software product lines certainly are composed of components, these components are all specified by the product line architecture. Moreover, the components are assembled in a prescribed way, which includes exercising built-in variability mechanisms in the components to put them in use in specific products.. 2.2.1.4.. Just a Reconfigurable Architecture. Reference architectures and object-oriented frameworks are designed to be reused in multiples systems and to be reconfigurable as necessary. A SPL architecture is designed to support the variation needed by the products in the product line, thus making it reconfigurable makes sense. But the product line architecture is just one asset, even though an important one, in the product line’s asset base. Some authors also compare frameworks to software product lines (Pasetti & Pree, 2000). In this specific case, we consider that frameworks can be compared to SPLs if they explicitly model the commonality and variability among the products involved.. 2.2.1.5.. Releases and Versions of Single Products. Organizations routinely produce releases and versions of products. Each of these new versions and releases is typically constructed using the architecture, components, test plans, and other features of the prior releases. Considering this context, a SPL product is different mainly because: first, it contains multiple simultaneous products, all of which are going through their own cycles of releases and versioning system; second, in a single-product context, once a product is updated, there’s often no looking back, but in product lines an early version of a product that is still considered to have market potential can easily be kept as a viable member of the family..

(32) Chapter 2 – Software Product Line Concepts. 2.2.1.6.. 16. Just a Set of Technical Standards. Many organizations set up technical standards to limit the choices their software engineers can make regarding the kinds of sources of components to incorporate the systems and different possible architecture forms, considering different patterns in literature (Gamma et al., 1995). On the other hand, an organization that undertakes a SPL effort may have such technical standards, in which case the components and product line architecture will need to conform to those standards. However, the standards are simply constraints that are inputted to the SPL, no more.. 2.3. Benefits of Software Product Lines As we described what software product lines are and what they are not, it is also important to discuss a little about which are the benefits of applying such approach. These benefits are shown in the following subsections and involve technical and non-technical aspects.. 2.3.1. Enhancement of Quality The artifacts in a SPL are reviewed and tested in many products. They have worked properly in more than one type of product. The extensive quality assurance across all the products in the SPL implies a significantly higher chance of detecting faults and correcting them, thereby increasing the quality of all products (Pohl et al., 2005).. 2.3.2. Reduction of Maintenance Effort Considering that during the establishment of a software product line, the artifacts are supposed to have higher quality since they are being reused and tested across different products, we can conclude that less maintenance effort is spent within these artifacts. Additionally, if an artifact has to be changed because of an eventual error, the changes can be propagated to all products in which the artifact is being used. The techniques used in product line engineering make a system better maintainable as stated in (Coplien, 1998)..

(33) Chapter 2 – Software Product Line Concepts. 17. 2.3.3. Reduction of Development Costs Major changes in engineering practices are usually surrounded by economical justification. An essential reason for introducing product line engineering is the reduction of costs. When artifacts are reused in several systems, this implies a cost reduction for each system. Obviously, before the artifacts can be reused, they must be developed and this involves an up-front investment to create the initial SPL infra-structure. Different authors agree with empirical investigations which revealed that only after approximately 3 systems deployed, the software product line becomes worth compared to single system development (Weiss & Lai, 1999), (Clements & Northrop, 2001). Figure 2.1 shows the accumulated costs needed to develop n different systems. The solid line sketches the costs of developing the systems independently, while the dashed line shows the costs for product line engineering. The location at which both curves intersect marks the break-even point. The strategy that is used to initiate a product line also influences the break-even point significantly (McGregor et al., 2002).. Figure 2.1. Costs for developing n kinds of systems as single systems compared to product line engineering (Weiss & Lai, 1999).. 2.3.4. Reduction of Time to Market One of the main advantages of SPL engineering compared to single system development is the reduction of time to market. For single-product development, we can assume it is roughly constant (Clements & Northrop,.

(34) Chapter 2 – Software Product Line Concepts. 18. 2001). For SPLs, the time to market indeed is initially higher, as the common artifacts have to be built first. Yet, after having passed this initial difficulty, the time to market is considerably reduced.. Figure 2.2. Time to market with and without product line engineering. (Pohl et al., 2005).. 2.3.5. Improving Cost Estimation Once the core assets base used in a SPL is already built, it becomes easier for the team involved to estimate the cost of new products. This happens mainly because the team involved knows precisely what is needed to be done to integrate the components in the base and what is needed to be implemented to deploy a new functionality for a new product in the product line. Cost estimations become as more precise as the product line reaches a higher level of maturity.. 2.3.6. Benefits for the Customers Customers obtain products adapted to their needs and wishes. However, in the past it did not work like that because users had to adapt their own way of working to the software. It often happened that customers had to get used to a different user interface and a different installation procedure with each new product. This annoyed them, is some situations, in particular as it even happened when replacing one version of a product by the next version. Then, users started to request for improved software ergonomics. In this context, software product lines can bring great benefits for the customers. Firstly.

(35) Chapter 2 – Software Product Line Concepts. 19. because customers can purchase these products at a reasonable price as product line engineering helps to reduce the production costs. Additionally, customers get higher quality products since the reusable components and their configurations have been tested in many products developed earlier. Moreover, despite possessing individual features, the products of a product line have a lot in common due to the reused artifacts in the platform. Similar user interfaces and similar major functionality make it easy for the customer to switch from one product to another. The customer does not have to learn new ways of using another product derived from the same platform.. 2.4. Maturity and Evolution in Software Product Lines Adopting a SPL approach is not an easy task. It may take years for an organization to reach acceptable maturity in a given domain and be a good candidate for applying such approach (Bosch, 2002). Figure 2.3 shows one possible way to understand the maturity levels of a software product line proposed by (Bosch, 2002).. Figure 2.3. Maturity levels for software product lines (Bosch, 2002)..

(36) Chapter 2 – Software Product Line Concepts. 20. Starting from a situation in which each product or application is developed independently, the main maturity development path consists of: •. A standardized infrastructure: consists of the basic infrastructure based on which new products are developed. This infrastructure is generally composed of the operating system and the typical commercial components on top of it, such as a database management system and a graphical user interface. In addition, the organization may acquire some domain-specific components from external sources. These components are typically integrated through some proprietary glue code.. •. A platform: it usually includes a standardized infrastructure and, on top of that, it captures all functionality that is common to all products or applications. The common functionality that is not provided by the infrastructure is implemented by the organization itself, but typically the application development treats the platform as if it was an externally bought infrastructure.. •. A software product line: once the benefits of exploiting the commonalities among the products become more accepted within the organization, there may be a consequent development in order to increase the amount of functionality in the platform to the level where functionality common to several, but not all, products become part of the shared artifacts. Then, the stage of a software product line is reached.. •. A configurable product base: at this stage, the organization, rather than developing a number of different products, moves towards developing only one configurable product base that, either at the organization or at the customer site, is configured into the product bought by the customer. Two additional developments can be identified, i.e. product populations. and a program of product lines. A product population approach is chosen when the organization decides to increase the scope in terms of the number of products. The program of product lines is selected when the scope of the product line is extended in terms of the supported features (Bosch, 2002)..

(37) 21. Chapter 2 – Software Product Line Concepts. Understanding which is the current maturity level of an organization and which are the next levels to evolve can help on the SPL adoption. It is also important to mention that the SPL adoption will likely fail if the levels are skipped, for example, if an organization is using a standardized infrastructure and tries to implement a configurable product base. Problems may happen because deep organizational changes are needed and also because there are several. non-technical. aspects. involved,. such. as. organization. culture,. management commitment and funding, among others (Bosch, 2004).. 2.5. Successful Cases in Software Product Lines There are many successful cases of software product lines application. In order to recognize distinguished members of a community in a field of endeavor, the Software Engineering Institute (SEI, 2008) established the SPL hall of fame (SPL Hall of Fame, 2008). Each Software Product Line Conference (SPLC) culminates with a session in which members of the audience nominate systems for induction into the SPL Hall of Fame. Those nominations feed discussions about what constitutes excellence and success in product lines. The goal is to improve SPL practice by identifying the best examples in the field. Nominations are voted on at the next SPLC by the majority of those present. The following subsections show four cases of successful SPL application which have drawn attention of academia and have been nominated to the hall of fame. The subsections are arbitrarily ordered. In spite of those successful examples, one particular failure case in the software reuse area that is commonly mentioned is the Ariane 5 case (Jezequel & Meyer, 1997). On June 4, 1996, the maiden flight of the European Ariane 5 launcher crashed, about 40 seconds after takeoff. Media reports indicated that a half-billion dollars was lost. The failure was caused by an error occurred in the Inertial Reference System (IRS) before takeoff. The IRS was reused from the former versions of Ariane. According to the inquiry board a main lesson learned of this fact was that reuse without a precise, rigorous specification mechanisms can be a risk of potentially disastrous proportions..

(38) Chapter 2 – Software Product Line Concepts. 22. 2.5.1. Philips Royal Philips Electronics of the Netherlands is one of the world’s biggest electronics companies and the largest in Europe. Its products vary from professional medical systems to lighting, consumer electronics, and domestic appliances (Philips, 2008). Philips is one of the leading commercial European researchers in the field of software product lines, with some successful examples, such as the SPLs of consumer electronics (Ommering, 2000) and medical imaging systems (Wijnstra, 2000). In the field of consumer electronics, Philips’ portfolio includes audio– video equipment, like TV-sets, radio receivers, CD and DVD players and recorders, as well as set-top boxes (Philips, 2008). In this field, the customers have high demands with respect to performance and due of the mass-market nature, the cheapest memory and processor chips are used. Moreover, the products have to be very reliable as they are offered in the mass market. Hence, repairing them after delivery is very costly (Ommering et al., 2000). In order to handle those specific characteristics of the early mentioned field, the consumer electronics division has chosen to use a composition paradigm in the production of the product lines. The methodology is named Koala (Ommering, 2002). This means that the architecture has enough flexibility to allow many different configurations of the same basic components. The whole set of products is referred to as product populations, with many differences and many commonalities. Components are combined to build more complex components. Interfaces that do not match are connected through glue code. Certain pieces of glue code are standard, and only need some parameters to instantiate. As a result to the Koala application, by 2002, all mid- and high-range TV sets, and many other products as well, were produced in the population (Ommering, 2004). Nowadays, there are 20 different software releases per year, where each release serving 1-5 different product types. The product line supports three different hardware platforms. As a good model to be followed, the architecture did not need many adaptations after its first conception in 1996. This has proven that having a stable reference architecture is a major advantage..

(39) Chapter 2 – Software Product Line Concepts. 23. On the other hand, in the field of medical imaging systems, Philips’ portfolio of medical systems includes products such as X-ray, ultrasonic or computed tomography and services such as training, business consultancy, or financial services (Philips, 2008). In order to handle with the increasing complexity and diversity in this domain (Wijnstra, 2000), the medical systems division has decided to employ a SPL approach. A medical middleware platform serves as the basis for other software product lines in the company. Thus the platform is a software product line in itself, which leads to additional variability requirements for the platform. The component-based reference architecture reuses existing software components that are transformed step by step into domain artifacts. As a result, since 2001, the number of products that use the common platform developed in the SPL has increased. By 2004, ten product groups were based on the platform.. 2.5.2. Hewlett-Packard (HP) HP is one of the world’s leading IT companies with many different business areas, reaching from consumer handheld devices to powerful supercomputer installations (HP, 2008). One reason that most contributed for HP to reach this position was the reuse program, initiated in the early 1980s (Griss, 1994), (Griss, 1995), and the adoption of a SPL approach (Toft et al., 2000). One important business area is the manufacturing of printing technology. HP must maintain a wide range of different firmware used in several products for printing, copying, scanning, and faxing. In the late 1990s, HP initiated the Owen Firmware Cooperative to install a software product line approach. Several product teams build a community to provide the product line in a cooperative way. Every product team adopts ownership of newly produced or significantly changed core assets, so everyone feels responsible for the quality of the platform. A small platform team ensures the robustness of the core assets and guides the product teams in using the core assets (Toft et al., 2000). The software product line approach yields a reuse rate of about 70% for new products. About 20% of the application assets are based on slightly modified core assets and only 10% require writing new code. Owen products.

(40) Chapter 2 – Software Product Line Concepts. 24. have been produced using 25% of the staff, in 33% of the time, and with 96% fewer bugs than earlier products.. 2.5.3. Boeing The Boeing Company is one of the leading manufacturers of commercial jetliners, military aircraft, satellites, missile defense, human space flight, and launch systems (Boeing, 2008). The Bold Stroke software product line was originally initiated in 1995 at McDonnell-Douglas which, in the meantime, merged with the Boeing Company. The purpose of the product line was to improve reuse potentials in the Operational Flight Program (OFP) software across multiple fighter aircraft platforms (Sharp, 2000). OFPs are mission-critical, distributed, real time embedded applications supporting the avionics as well as the cockpit functions for the pilot The first step of introducing Bold Stroke included the definition of a reference architecture and its proof of concept, including hardware, software, standards, and practices. The main challenge when defining the reference architecture was to harmonize the differences in the avionics subsystems, mission computing hardware, and system requirements (Doerr & Sharp, 2000). The success of the Bold Stroke software product line is based on the reduction of dependencies between components and the dependency on platform-specific hardware. The software design facilitates the modification of components and maximizes the reuse in different OFPs (Doerr & Sharp, 2000). The Bold Stroke software product line was flight tested successfully on several different aircraft platforms hosted on different hardware configurations (Sharp, 2000).. 2.5.4. Nokia Nokia is the world leader in mobile communication, holding approximately 40% of the global mobile phone market (Nokia, 2008) and the company believes that software product line engineering has helped them to reach that position. Every year, approximately 30 different phones are manufactured to be distributed in more than 130 countries. This scenario is quite challenging considering the.

(41) Chapter 2 – Software Product Line Concepts. 25. main diversity Nokia’s product line must support, for instance, it must cover six different protocol standards, 58 different languages, phones with a variable number of keys, a wide variety of functional features and capabilities, different user interface designs, and many platforms and environments (Heie, 2002). Moreover, these features must be configurable and pluggable. To establish its product line, Nokia is organized in software lines, which are groups of people developing a specific set of features for a wide range of products. Constantly, a new release is created by one group for others to use. The company has different software lines for different levels of software, such as, Digital Signal Processing (DSP), architecture, user interface, etc. Each software line can potentially deliver to all products. Each deliverable must be tested in as many configurations as possible. A global data base of feature dependencies is maintained to ensure all affected parties are up-to-date on changes. In fact, there is a lot of complexity involved with Nokia’s product line considering backward compatibility, new technologies, operator requirements, bugs, cultural values and so on (Heie, 2002). One component that may exemplify the diversity of Nokia’s product line is the language component. It must support about 58 different languages, including non-Latin languages, such as, Chinese, Arabic, Korean, Hebrew and Thai. Some of these languages are written from right to left. To complicate this further, T9 optional feature must be supported. T9 feature helps the user to type texts using the phone keyboard by guessing the word being typed without the need of spelling that word letter by letter and not causing the user to press the keys many times. What is more, when setting the phone language, all texts in display must be automatically changed. To implement this component, they had to separate language knowledge from the code – abstractly speaking, separate appearance from behavior. They used the Observer design pattern and created a text database where the texts are defined. Doing it this way, the texts are resolved during display updates. As the main result, whatever language is chosen, the code does not change, thus adding a language is transparent (Heie, 2002). The initial software architecture for Nokia’s product line addressed variations in hardware, communication standards, and user interfaces. The.