MASTER THESIS Software Product Line Architectures

MASTER THESIS Software Product Line Architectures

School of Innovation, Design and Engineering (IDT) MASTER THESIS SOFTWARE ENGINEERING ADVANCED LEVEL 30 HP Software Product Line Architectures: Reviewing the Literature and Identifying Bad Smells Author: Hugo Sica de Andrade ([email protected]) Supervisor at MDH: Ivica Crnkovic Supervisor at UFBA: Eduardo Almeida Examiner: Ivica Crnkovic September 2013 Abstract The Software Product Line (SPL) paradigm has proven to be an effective way to achieve large scale reuse in different domains. It takes advantage of common aspects between different products, while also considering product specific features. The architecture plays an im- portant role in SPL engineering, by providing means to better under- stand and maintain the product-derivation environment. However, it is difficult to evolve such architecture because it is not always clear where and how to refactor. The contribution of this thesis is twofold. First, the current state of the art of software Product Line Architectures (PLAs) is investigated through a systematic mapping study. It provides an overview of the field through the analysis, and categorization of evidence. The study identifies gaps, trends and provides future directions for research. Fur- thermore, this thesis addresses the phenomenon of architectural bad smells in the context of SPLs. A case study provides an investigation on the implications of such structural properties in a variability-based environment. Prior to the search for smells, the architecture of a sam- ple SPL in the text editor domain is recovered from the source code. Abstrakt Software Product Line (SPL) paradigmet har bevisat sig vara ett effektivt s¨att att uppn˚astorskalig ˚ateranv¨andning i olika dom¨aner. Den drar nytta av gemensamma aspekter mellan olika produkter, och ¨overv¨ager samtidigt ¨aven produktspecifika egenskaper. Arkitekturen spelar en viktig roll i SPL tekniken, genom att tillhandah˚alla medel f¨or att b¨attre f¨orst˚aoch underh˚alla “product-derivation” milj¨on. Det ¨ar dock sv˚art att vidareutveckla s˚adan arkitektur f¨or att det inte alltid ¨ar tydligt var och hur den kan omstruktureras. Bidraget fr˚andenna avhandling ¨ar tv˚afaldigt. F¨or det f¨orsta, den aktuella situationen f¨or “software Product Line Architectures” (PLAs) unders¨oks genom en systematisk kartl¨aggning. Den ger en ¨oversikt av f¨altet genom analys, och kategorisering av bevis. Studien identifierar luckor, trender och ger framtida riktlinjer f¨or forskning. Vidare adres- serar denna avhandling fenomenet arkitektoniska “bad smells” inom kontexten f¨or SPLs. En fallstudie ger en utredning av implikationer av s˚adana strukturella egenskaper i en variabilitet-baserad milj¨o. Innan s¨okningen av “smells”, ¨ar arkitekturen fr˚anen sampel SPL i textredi- gerar dom¨anen ˚atervunnen fr˚ank¨allkoden. i Contents 1 Introduction 1 1.1 Goals . 1 1.2 Structure of the Thesis . 2 2 Background 3 2.1 Software Product Lines . 3 2.2 SoftwareArchitecture. 4 2.3 Terminologies . 5 3RelatedWork 7 3.1 Reviews . 7 3.2 PLAAssessment ......................... 8 4 Mapping Study 10 4.1 Review Method . 10 4.2 Review Process . 11 4.3 Planning . 11 4.3.1 Research Questions . 12 4.3.2 Viewpoints ........................ 14 4.3.3 Search Strategy . 14 4.4 Conducting . 15 4.5 Screening of Papers . 17 4.6 Classification Scheme . 17 4.7 Data Extraction . 19 5 Review Outcomes 21 5.1 Findings.............................. 23 5.1.1 RQ1 - Are architectural patterns (or styles) used in SPL? 25 5.1.2 RQ2 - How is variability handled in the architecture level of SPLs? . 29 5.1.3 RQ3 - How are the SPL architectures documented? . 34 5.1.4 RQ4 - How are the SPL architectures evaluated? . 39 5.2 Discussion . 42 5.2.1 Patterns . 43 5.2.2 Variability . 44 5.2.3 Documentation . 45 ii 5.2.4 Evaluation . 45 6 Case Study: Analyzing Bad Smells 47 6.1 NotepadSPL ........................... 48 6.1.1 Feature Model . 48 6.1.2 Variability Management . 49 6.1.3 Product Map . 50 6.2 ArchitectureRecovery . 51 6.2.1 Recovery Process . 53 6.2.2 AutomatedAnalysis . 53 6.2.3 ManualAnalysis ..................... 55 6.2.4 MergingProductArchitectures . 57 6.3 ArchitecturalBadSmells. 58 6.3.1 Connector Envy . 60 6.3.2 Scattered Parasitic Functionality . 61 6.3.3 Ambiguous Interfaces . 62 6.3.4 ExtraneousAdjacentConnector . 62 6.3.5 Feature Concentration . 63 6.4 Discussion . 64 7 Threats to Validity 66 8 Conclusion and Future Work 67 Appendix A List of Journals Manually Searched 85 Appendix B List of Conferences Manually Searched 86 Appendix C List of Primary Studies According to Aspects in PLA (next page in landscape) 87 Appendix D Notepad SPL Architecture Specification 92 iii List of Figures 1SPLFrameworkproposedbyPohletal.(2005)........4 2 Review process proposed by da Mota Silveira Neto et al. (2011) 11 3CoveredtopicsinPLAresearch.................12 4Screeningofpapers........................18 5Distributionofstudiesinpublicationyears...........22 6Overviewoftheareathroughabubbleplot...........24 7 Numberofstudiesaddressingresearchtopics . 25 8 Artifactsaffectedbyvariability . 34 9 Architecturalviewsaddressedinthestudies . 38 10 Evaluation methods addressed . 41 11 FeatureModelfortheNotepadSPL. 49 12 ArchitectureRecoveryProcess . 53 13 DecompositionViewofNotepadSPL . 54 14 DependencyViewofNotepadSPL . 55 15 NotepadSPLComponentModel. 58 List of Tables 1SearchString...........................15 2ResearchTypeFacet.......................20 3Top12contributingpublicationsources.............21 4 PatternsinPLAs ......................... 27 5 NotepadSPLProductMap ................... 51 6 NotepadSPLVariabilityPoints . 57 C.7 PrimaryStudiesaddressingPatterns . 88 C.8 PrimaryStudiesaddressingVariability . 89 C.9 Primary Studies addressing Documentation. 90 C.10 Primary Studies addressing Evaluation . 91 iv 1. Introduction Due to the critical dependence of society on software, increasing respon- sibility is attributed to the software engineering community. The effects of the failure of a system may spread beyond the system itself, because of the integration between systems that earlier were stand-alone. The result is a significant amount of scientific research that aim to either gather evidence or propose new ways to successfully plan and maintain those environments. In order to handle the complexity and the needs from these previous remarks, several approaches appeared in the software engineering scenario. One of such relevant approaches is Software Product Lines (SPLs) – an approach for exploiting variability, taking advantage of the common aspects of different software systems. Software product lines aim to attend to chal- lenges through a set of core assets developed for reuse in the products that constitute the product line with up-front analysis, design, implementation, and so on (Clements and Northrop, 2001). The main step in the process is the design of the Product Line Architecture (PLA), through which business goals must be reflected and treated towards the derivation of products. Since the development of a SPL involves the (often complex) implementa- tion of different structures, processes, interfaces and activities, it is relevant for product line practitioners to pay sufficient attention to its architecture. The reuse of software artifacts is a key element in SPL practice, thus it is important to build a favorable environment that supports such practice, as well as a solid architecture related to it. The implementation of core assets – along with their uses – should obey a set of organization rules in order to successfully achieve faster time-to-market and efficient management goals. It is important to properly evaluate the PLA aiming its adequate and consistent evolution. PLAs have a longer life span and should support a range of products, being responsible for their quality attributes (Etxeberria and Mendieta, 2005). The interactions of product quality attributes require- ments may lead to architectural conflicts (Olumofin and Misic, 2007) and consequently interfere in the assessment of PLAs. In addition, organiza- tional issues may affect the evaluation of PLAs, due to their larger scope and commonly high number of stakeholders involved. 1.1. Goals Many studies reported solutions regarding different aspects of design and using different methods, but none aimed at gathering relevant information 1 for synthesizing knowledge in PLA research. In this sense, the purpose of this work is twofold. The first is to select and review the current literature publications in a systematic way, providing an overview of the existing studies discussing architecture aspects of SPLs. By presenting an up-to-date state of research, we help both practitioners in understanding the phenomenon and researchers in identifying gaps, trends and current challenges in this field. Then, we aim at searching for points of improvement in PLAs through the identification of architectural smells.Thetermreferstoarchitectural decisions that negatively impact system lifecycle properties, such as under- standability, testability, and extensibility. It was originally proposed for the assessment of single systems, thus, our goal is to characterize architectural bad smells in the context of PLAs. Prior to the search, we selected a sample product line in the domain of text editors and recovered its architectural attributes. 1.2. Structure of the Thesis The remainder of this thesis is organized as follows: we start by discussing background information in Section 2. Section 3 describes the related work. Section 4 describes the review method and the process of mapping studies. Section 5 presents

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    99 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us