ANTTI TIRILÄ VARIABILITY ENABLING TECHNIQUES FOR SOFTWARE PRODUCT LINES. Master of Science Thesis - PDF

Description
TAMPERE UNIVERSITY OF TECHNOLOGY Department of Information Technology ANTTI TIRILÄ VARIABILITY ENABLING TECHNIQUES FOR SOFTWARE PRODUCT LINES Master of Science Thesis Subject approved by the department

Please download to get full document.

View again

of 65
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information
Category:

Memoirs

Publish on:

Views: 33 | Pages: 65

Extension: PDF | Download: 0

Share
Transcript
TAMPERE UNIVERSITY OF TECHNOLOGY Department of Information Technology ANTTI TIRILÄ VARIABILITY ENABLING TECHNIQUES FOR SOFTWARE PRODUCT LINES Master of Science Thesis Subject approved by the department council September 18 th 2002 Examiners: Prof. Tommi Mikkonen (TUT) Kai Närvänen (Nokia Mobile Phones) FOREWORD I have written this thesis as a research assistant in the Software Systems Laboratory of Tampere University of Technology. I would like to thank my examiner and mentor, Professor Tommi Mikkonen for teaching the basics of scientific writing, and for some great ideas of how to conduct the research behind this thesis. I would also like to thank Professor Kai Koskimies for visions in the field of software product lines. Furthermore, I would like to thank Kai Närvänen at Nokia Mobile Phones for providing the case study and vital information on their software architectures. For help and ideas on variability management I would like to thank Tommi Myllymäki and all the members of the Archimedes group. Finally, for love and understanding I would like to thank my friends and family, and above all my wife Hanna-Mari and son Joona. Tampere, Antti Tirilä Insinöörinkatu 58 C Tampere Tel ii ABSTRACT TAMPERE UNIVERSITY OF TECHNOLOGY Department of Information Technology / Institute of Software Systems TIRILÄ, ANTTI: Variability Enabling Techniques for Software Product Lines Master of Science Thesis, 59 pages. Examiners: Prof. Tommi Mikkonen and Kai Närvänen Funding: Archimedes project (Tekes, industry) May 2003 Keywords: software product line, arhitecture, variability Software production is potentially very labor intensive work, and large systems tend to be rather error prone. The software community quite unanimously sees that the reuse of existing software assets is the key to overcome these problems. A software product line is a set of software systems (a product family) that share a common software architecture and a set of reusable components. One of the most challenging aspects of software product lines is variability management. That is, how to describe, manage and implement the commonalities and differences between individual product family members. In this thesis we describe the basic concepts behind the product family thinking and especially cover the different issues regarding variability in software product lines. The main focus of this thesis is on introducing the actual variability enabling techniques. Moreover, we present an evaluation framework that describes the different aspects and requirements for variability enabling techniques. Nokia Symbian OS Target Architecture was used as a case study, and the final purpose of the technique evaluation was to find most usable techniques within the target architecture. Successful adaptation of the product family concept is essentially an organizational effort. However, there are techniques that enable the implementation of variability points more efficiently than others, depending on the architecture and used programming paradigms. For large organizations producing large software systems we propose a combination of a hierarchical organizational model where each sub-organization (and subsystem) is a product line itself (and thus, a basic unit of reuse) and a set of three different techniques among which every sub-organization can choose the one that best suits their needs. Cooperation between subsystems is guaranteed by binding the variability points before the actual integration process. iii TIIVISTELMÄ TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan osasto / Ohjelmistotekniikan laitos TIRILÄ, ANTTI: Varianssin toteutustekniikat tuoterunko-arkkitehtuureissa. Diplomityö, 59 sivua. Tarkastajat: Prof. Tommi Mikkonen sekä Kai Närvänen Rahoitus: Archimedes projekti (Tekes, teollisuus) Toukokuu 2003 Avainsanat: tuoterunko-arkkitehtuuri, arkkitehtuuri, varianssi Ohjelmistojen tuottaminen on tyypillisesti hyvin työläs prosessi, ja suuriin järjestelmiin jää helposti virheitä, joita ei edes testausprosessin aikana löydetä. Ohjelmistoalan ammattilaisten ja tutkijoiden keskuudessa ollaan yleisesti sitä mieltä, että nämä ongelmat voitaisiin ratkaista ohjelmien uudelleenkäytöllä. Tuoterunko-arkkitehtuuri koostuu joukosta ohjelmistotuotteita, joilla on yhteinen arkkitehtuuri ja jotka koostuvat pitkälti yhteisistä, uudelleenkäytettävistä komponenteista. Yksi vaikeimmista asioista tuoterunko-ajattelussa on varianssin hallinta, eli se kuinka kuvataan ja toteutetaan tuoteperheen jäsenten väliset eroavaisuudet ja yhteiset osat. Tässä diplomityössä esitellään tuoterunko-arkkitehtuurit yleisellä tasolla keskittyen varianssin hallinnan eri osa-alueisiin. Työssä esitellään joukko varianssin toteutustekniikoita sekä tekniikoiden arviointiin soveltuva joukko kriteerejä ja menetelmiä. Esimerkkiarkkitehtuurina toimii Nokian Symbian OS-tavoitearkkitehtuuri, jonka pohjalta yrityksen uudet tuotteet luodaan. Työn tavoitteena on löytää käyttökelpoisimmat varianssin toteutustekniikat ja menetelmät kyseiseen arkktehtuuriin. Menestyksekäs tuoterunko-arkkitehtuuri perustuu ensisijaisesti siihen, että yrityksen organisaatio ja prosessit tukevat tätä ajattelua. Riippuen arkkitehtuurista ja käytetyistä ohjelmointiparadigmoista, toiset tekniikat soveltuvat varianssin toteuttamiseen paremmin kuin muut. Suuria ohjelmistoja tuottaville suurille organisaatioille työssä suositellaan hierarkista organisaatiomallia, jossa kukin aliorganisaatio hallitsee omaa pientä tuoterunkoansa ja tällöin uudelleenkäyttö tapahtuu yksikkökohtaisesti. Tähän liittyen työssä suositellaan kolmea eri tekniikkaa, joiden joukosta kukin yksikkö voi valita käyttöönsä parhaiten soveltuvan. Eri alijärjestelmien ja komponenttien yhteensopivuus taataan sillä, että varianssipisteet sidotaan ennen varsinaista integrointiprosessia. iv CONTENTS 1. INTRODUCTION SOFTWARE PRODUCT LINES SOFTWARE ARCHITECTURES PRODUCT LINE ARCHITECTURES Introduction to Product Line Architectures Core Asset Development Product Development Management Activities VARIABILITY IN SOFTWARE PRODUCT LINES TERMS AND CONCEPTS MODELING VARIATION MAPPING VARIATION MODEL TO IMPLEMENTATION LAYERED PLATFORM ARCHITECTURES COMPONENT DEVELOPMENT AND EVOLUTION VARIABILITY ENABLING TECHNIQUES PREPROCESSOR DIRECTIVES PARAMETERIZATION FRAME-LIKE TECHNIQUES OBJECT-ORIENTED TECHNIQUES Delegation Inheritance Design Patterns Frameworks LIBRARIES CONFIGURATION EVALUATION PREPROCESSOR DIRECTIVES PARAMETERIZATION X-FRAMES OBJECT-ORIENTED FRAMEWORKS STATIC LIBRARIES v 5.6 DYNAMIC LINK LIBRARIES CONFIGURATION VARIABILITY MANAGEMENT IN NOKIA SYMBIAN SW ARCHITECTURE DOMAIN OVERVIEW Symbian OS Symbian OS as a Layered Platform Architecture PRESENT SITUATION AND PROBLEMS PROPOSED SOLUTIONS The Concept of Multiple Coexisting Product Lines Preprosessor Directives Object-Oriented Frameworks X-frames Dynamic Link Libraries CONCLUSIONS REFERENCES vi 1. INTRODUCTION As we well understand, the modern world is more and more dependent on software. Many experts consider that software has been a key factor of the economic growth in the 1990s. Software is responsible for making the world smaller, and electronic devices are more and more software driven. However, software production is very labor intensive, and large systems tend to be rather error prone. The software community quite unanimously sees that the reuse of existing software assets is the key to overcome these problems. Several approaches have been introduced to enable reuse during the past decades. The 1970s introduced modules as reusable software entities, however the current status quo still is that modules have to be adapted by hand via editing the source code. The 1980s brought object-orientation that introduced the concept of a class as a basic unit of reuse. Inheritance associated with object-orientation is a powerful mechanism to adapt code, but for some reason object-orientation has failed to fulfill the promises of high reuse levels. The 1990s has been the prime time of software components. The problem with the straightforward component thinking is that the bigger the component, more specialized it tends to be. On the other hand, small components are not efficient (in terms of reuse) because of the development overhead reuse introduces. It is easier to write one-of, specialized component for all software products separately. Software product line is a set of software systems that share a common software architecture and a set of reusable components (designed for that particular application domain) [Bo00]. In other words, this set of software systems share a common, managed set of features, and the individual product implementations are based on some common set of core assets (which is more than just software components). Moreover, this core asset usage is carried out in a well documented, prescribed way to maximize the reuse potential. One of the most challenging aspects of software product lines is variability management. That is, how to describe, manage and implement the commonalities and differences between individual product family members. [My02] gives an excellent overview of the variability management, and especially in higher levels of the design. In this thesis we study the possible (low level) techniques that can be used to actually implement the required variance. Our case study is Nokia Mobile Phones (NMP) Symbian OS target architecture [Le02]. NMP develops and maintains a wide variety of products in the wireless information devices domain, in particular mobile phones. Resent products have been based on Symbian OS and similarities between these products are significant which makes mobile phones a prime example of a product family. Reuse potential is great but suffer from a lack of suitable variability enabling techniques and practices. The case study sets some requirements and restrictions to the techniques we have evaluated. They are listed as follows: Product line target architecture is based on existing products. Product line target architecture is based on Symbian OS and implemented in C++ language. Techniques must be applicable right away, with today s tools and techniques. This thesis is structured as follows. Chapter 2 gives an overview to software architectures in general, and to the aspects of actual product line architectures. Chapter 3 presents general issues of variability in software product families. Also, this chapter covers the issues of predesigned and unpredicted variance. Furthermore, this chapter describes how variance relates to an architectural style which is typical among product line arhitectures. Actual techniques and their usage are presented in chapter 4, and their suitability for product line usage is evaluated in chapter 5. We present a number of evaluation criteria and reflect the techniques capabilities agains them. Chapter 6 describes out case stydy and proposed solutions. Chapter 7 contains the conclusions and outlines some future research directions. 2 2. SOFTWARE PRODUCT LINES As already stated in the previous chapter, one (and probably the most important) property of members of a software product line is that they share a common software architecture. Without a common architecture there cannot be common software assets and thus, no reuse. In this chapter we outline the basics of software architectures, and what is required to maximize the commonalities and manage differences between similar software products. The discussion in sections 2.1 and 2.2 is primarily based on [Bo00], [ClNo02] and [Ha01]. 2.1 Software Architectures Virtually every respectable research scientist in the area of software architectures has his/her own definition for the term software architecture. A nice collection of these definitions can be found in [Ca02]. However, majority of these definitions present three main characteristics for software architectures. 1. Architecture describes the high-level decomposition of the system, i.e. the main components (or subsystems) and the structure of the system. 2. Architecture describes the externally visible properties and interconnections of these top-level components. This includes the basic behavioral responsibilities. 3. Architecture explicitly presents guidelines and rationale for design and evolution of the aforementioned components. The fourth, almost as common, part of an architecture seems to be a collection of stakeholders need statements (requirements). The idea of an architecture is to give highenough level of abstraction over the system, so that it can be viewed as a whole. Naturally, the size of the system can vary, and thus, any exact granularity for the abstraction cannot be given. The second and third points given above are at least as important as the first one. They are needed for successful assessment of the architecture, as well as making the architecture understandable for all stakeholders. 3 Architecture is derived from a set of quality and functional requirements. Therefore the structure (static and dynamic) is supposed to support these requirements. Implementation details are always omitted from architecture description. [Bo00] outlines three purposes for explicit presentation of an architecture. Firstly, it acts as a basis for quality attribute assessment. Then functional attributes are considered less important ones, and we just want to see if the architecture is capable of fulfilling the quality requirements. In practice, the chosen architecture imposes theoretical limits for the quality attributes of the system. Secondly, explicitly described architecture allows better communication between the stakeholders early in the development process. This is important because quality and functional requirements coming from different stakeholders are sometimes conflicting, so architectural trade-offs can be agreed on, as early as possible. Finally, architectural description defines the shared components in a software product line. A product belongs to a product line when it shares the same basic architecture and thus some components with the product line. The design process of a software architecture may involve several different steps. Three most usual steps (based on [BaKa99] and [Bo00]), especially in an iterative design process, are functionality-based architecture design, architecture analysis & assessment and architecture transformation. Figure 2.1 presents a simplified, non-iterative process model. Iterative model would include a loop-back from quality estimation to requirement selection if new requirements were presented. Figure 2.1: Simplified architecture design process (not iterative) 4 Architectural design of the system is performed based on the requirement specification and its purpose is to identify the core abstractions of the system. These abstractions (archetypes) form the basic structure of the system. Being often highly abstract, they are not always easy to find from the application domain. Important activities in this phase also include system context definition (interfaces to entities outside the system) and architecture decomposition (into more concrete components). The latter is achieved by identifying and specifying the components and their relations in the system. Object-oriented design methods start by modeling the entities present in a particular application domain and organizing them in inheritance (and other) hierarchies. This is distinctively a bottom-up approach if we compare it to the functionality-based architectural design process, which should be very much a top-down approach [Bo00]. At this stage we are not interested in the details of the system. In addition to functional requirements, a system also has some quality attributes it has to fulfill. An essential part of an architecture design process is the evaluation of the architecture that was developed based on the functional requirements. This evaluation is done against the quality attributes the stakeholders have defined. Several different methods exist for evaluation. However, their usability highly depends on the nature of the system to be evaluated. In scenario-based evaluation, such as SAAM [Ka et al. 94] and ATAM [Cl et al. 01], a set of scenarios is developed for each quality attribute. These scenarios are supposed to be concrete samples of abstract quality attributes. For instance, the maintainability requirement may be specified by a set of change scenarios. The effectiveness of this approach is naturally dependent on the quality of the scenarios, how well they represent the quality attribute to be evaluated. Scenarios can be used to evaluate e.g. performance, maintainability, reliability, safety and security attributes. Simulation and prototyping can be used when there is time and/or resources to make partial implementations of the architecture. These approaches can be used to evaluate, for example, performance attributes. As a bonus, simulation can be used to evaluate the functionality as well. Mathematical modeling, like simulation, can be used to evaluate systems operational qualities and it is often used while engineering high-performance and real-time computing systems. Finally, experienced software engineers often have valuable ideas and intuition on good and bad designs. These can be based on experience or even logical reasoning. This is called experience-based assessment. Architecture transformation is needed if the architecture does not fulfill the quality requirements. In general transformation means change. In the context of software 5 architectures transformation means a change that does not conflict with the functional requirements for that system. [Bo00] has identified four categories of architecture transformation. Imposing an architectural style (e.g. Pipes & filters, Layers, Blackboard) results in a complete reorganization of the architecture. This is naturally a big operation and thus styles should be considered in the initial design process. Imposing an architectural pattern is not a predominant operation, and the same patterns can be used inside many architectural styles. Architectural patterns should not be confused with design patterns. They can be seen as rules that deal with certain aspects of the system, such as concurrency or distribution. While the previous two transformation methods had architecture-wide impact, applying design patterns and converting quality requirements into functionality have more localized impacts, and they can be used to address problems in defined spots in the architecture (bottle-necks). Other important and quite obvious activities in architecture design process are architecture documentation and architecture maintenance. A good documentation is needed to give a concrete presentation of the architecture. Moreover, it has to include the rationale, the background for the design decisions. The rationale is important not only for the architecture at hand but also for the organization developing the architecture. Therefore, the documentation acts as an archive for the design knowledge inside the organization. Finally, architecture must be maintained because changes to requirements may (and will) appear during the lifetime of the architecture. However, architects have to be extremely careful with these new requirements, because they may well be contradictory to the existing set of requirements. Thus they should be evaluated carefully before any architecture transformation takes place. 2.2 Product Line Architectures The previous section dealt with the design of an architecture for single system or software product. As implied in the beginning of this chapter, software components for individual systems are usually not so reusable in other systems as the community wishes. Product-line architecture (PLA) is (more or less) common for all the members in a set of related products (a product family). The relations of these products result from the fa
Related Search
Similar documents
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x