Configuration Management for Software Product Lines

Transcription

1 onfigration Management for Software Prodct Lines Roland Laqa and Peter Knaber Franhofer Institte for Experimental Software Engineering (IESE) Saerwiesen 6 D Kaiserslatern, Germany {laqa, knaber}@iese.fhg.de STRT This position paper proposes a new approach to spport management of the assets sed for software prodct line deelopment. Examples for these assets are the domain (or prodct line) model, reference architectre, design, and code. New configration management concepts proide means to create, maintain, and eole these assets efficiently and consistently, inclding not only their common parts bt prodct-specific parts as well. 1 Introdction The basic concept behind software deelopment in prodct lines is goal-oriented deelopment for and with rese. Rese is achieed throgh synergistic effects dring deelopment and maintenance of common system parts. In order to plan and deelop these common parts to be sable by ftre members of the prodct line, it is necessary to consider the main ariabilities among the ftre prodcts dring modeling, architecting, design, and implementation. The commonalities are represented together with the main ariabilities in generic assets. There are two reasons for this separate treatment: First, tools to spport the maniplation of generic models inclding model instantiation 1 are basically not aailable. Ths, in traditional prodct line approaches, tools for single system deelopment are adapted or extended in sch a way that they proide some spport for genericity, at least the respectie notation. Second, keeping them separate from each other allows for the parallel deelopment and maintenance of prodct line members. Two general kinds of processes hae to be considered for generic prodct line assets: feed forward processes to derie them and to add new or change existing fnctionality and feed back processes to (re-)integrate changes or additions to prodct-specific assets into the common core in order to rese them in other prodcts as well. Feed back processes, especially, are difficlt and error prone 1.The term instantiation here refers to hiding model parts that do not belonging to a certain prodct and show the parts belong only to this prodct while checking existing constraints. becase traditionally, prodct-specifics are deeloped (and typically also stored) separately from the generic assets representing the common core. Ths, it is difficlt to decide if and which prodct-specific aspects shold be integrated into the core and it is een more difficlt to perform the integration. The lack of appropriate tools makes integration of prodct specifics into the common core extremely difficlt: there is basically no atomated spport for checking constraints on existing models if these constraints apply to model ariations, or to een represent them explicitly. Een traditional configration management tools do not proide enogh spport for these particlar problems (e.g., constraint checking on system ariants): They allow representation and checking of constraints bt do not spport prodct ariants (e.g., alternaties or options). The position we present in this paper can be briefly smmarized as follows: In order to spport management of prodct line assets appropriately, the definition of the way generic asset data are strctred has to be reflected in the spporting configration management system. This system has to be set-oriented, attribte-oriented, nification-oriented, and strctre-oriented. This position will be explained in the remaining sections of this paper. Section 2 presents the basic assets of a prodct line infrastrctre, in section 3 the configration management elements on which these prodct line assets hae to be mapped are explained. Problems of traditional configration management dring maintenance and eoltion of a prodct line are shown in section 4. Finally, the proposed configration management prereqisites for the maintenance of a prodct line infrastrctre are presented in section 5. 2 Software Prodct Line s The traditional software prodct line () infrastrctre consists of assets representing the prodct line (which are the smallest nits from a configration management point of iew), the relations between the assets, which are captred by the prodct line configrations.

2 Prodct line assets can be considered as intermediate software prodcts that are needed to prodce applications in a certain domain. They can be sbdiided into domain assets that captre the knowledge of the bsiness domain, and system assets representing the information specific for certain systems of the prodct line, which are needed to derie (e.g., parametrize, generate, instrment) the assets for these specific systems from the (generic) domain assets. Domain assets can be categorized into three grops: common assets (holding information that is identical for all members of the prodct line), generic assets (for captring information abot ariant parts of the software prodct line in one asset), and configration assets (representing the information needed to configre systems in the prodct line). ommon assets only hold information that is common for all members of the prodct line and contain no information specific to a certain system. These assets shold not ary becase they are sed in the same way by all members of the prodct line. Examples are database access libraries, which ery often can not be changed by the deelopers, or trace and log serices, which can be shared by most systems of a prodct line. assets captre information abot different ariants of a prodct line asset in one common asset in order to increase its resability and adaptability for different systems of a prodct line. The description of the different ariants strongly depends on the method sed, ery often it is achieed by means of the introdction of ariation points ia conditional blocks or by featre modeling methods (see [1],[2] pp.82). n example can be seen in [3], [5] p.8. There the optional and alternatie sb-components are decorated with conditional elements that are sed to decide whether or not the sb-component will be part of the specific prodct. onfigration assets contain the information on how to derie a specific asset from a generic one. n example is the decision model that describes the relation of possible decisions ([4]) in the bsiness domain and ariation points of a certain asset and how they can be resoled. System assets as mentioned aboe represent the information specific to a certain system of the prodct line and the knowledge needed to bild a certain system of the prodct line. assets describe information that is specific to a certain system or sb-grop of systems in the prodct line. Typically they contain no ariabilities and share less common parts with other assets. Examples are the description of the compilation parameters for a certain asset or GUI forms, which are ery often system specific. Prodction assets define a certain system of the prodct line. They configre the different parts that belong to a system and resole the decisions that are necessary to derie specific assets from generic ones. Examples are tples of decisions that resole ariation points in generic assets or makefiles that contain the dependencies between assets belonging to a certain system. Prodct Line System prodct line system defines all the domain and system assets necessary to bild a specific application from the prodct line infrastrctre. This means that all decision tples that are needed to resole the generic assets together with the appropriate decision models will be described as part of a prodct line system. Moreoer, all application specific assets sed are defined there. 3 onfigration Management Elements The main objectie of configration management (M) in is to spport maintenance of the prodct line infrastrctre. This means to spport management of the life cycle of the prodct line assets, their different cstomer specific ariants and reisions, their configration of the assets in specific systems, and their change oer time. In order to meet these reqirements, M systems mst be able to map elements onto their own strctres and to spport the different processes like deriation of specific assets and reintegration of changes. The basic elements of M systems to implement these reqirements are items (which are the elementary nits), configrations (which define the relations between items), reisions (for describing the change of items and configrations oer time), and ariants (which define different shapes of the same item or configration). Items Items are elementary nits of a software prodct that mst be niqely identified. They can be instantiated for different ersions (see Version on page 2). This definition is open to any kind of software prodct becase no type restriction is made. Items can be categorized in two grops: plain items that are not deried from any other items (bt neertheless can depend on others) and deried items that are deried from one or more other items (which again can be plain or deried). This distinction is needed becase the ersions of deried items also need the ersion information abot the plain items they stem from. Version ersion is an instance of an item. Two instances of the same item that are deeloped in parallel are related as ariants, whereas a ersion that follows by a change of another ersion of the same item is related to this ersion as a reision. The ariant relation defines alternatie forms, whereas a reision expresses the change of an item oer time. onfigration configration defines a composition of items and possibly frther configrations. onfigrations hae to obey the following rles: First, a configration can only be assigned to one ersion of a gien item, second, a ersion of an item

3 may be a member of seeral configrations, third, a configration can be recrsie, and forth, a configration ersion can be assigned to another configration. Mapping to M elements The mapping of elements to M elements creates a certain net of plain and deried items of generic, common, specific, prodction, and configration assets. The possible relations between and M elements, as well as the sorce assets they are deried from, are depicted in Table 1. orresponding M ommon onfigration Prodction Sorce of Deriation d Item + onfigration + Prodction d Item ommon + Prodction d Item + Prodction + onfigration + Prodction System onfigration Sbset of s + Sbset of ommon s + Sbset of s + Prodction s Table 1: - M element map 4 Problems of Traditional M for The traditional approach sffers from certain problems that arise in the different actiities of the change processes and that are related to the fact that the prodct line assets are treated as self-contained items in a M system withot considering the inner strctre of an asset. Typical problems are the reconstrction problem, the change propagation, and the consistency problem (which are related to the correctness of the prodct line and which emerge dring the change process), and the set problem (which describes difficlties in treating a set of systems instead of a single system). onsistency Problem: The reintegration of changes made in specific assets can lead to inconsistencies in another specific asset that is deried from the same generic asset. Therefore, the reintegration raises the need to adapt parts of the other specific asset. This happens, for example, if a certain part of a specific asset (figre 1) a common part that is shared by a specific asset and that was changed in the specific asset. The deriation of from ersion 2 of the generic asset wold then lead to an inconsistent specific prodct. This implies that before the generic asset can be sed for all specific assets that can be deried from it, all change effects hae to be determined and the changes hae to be integrated for reaching consistency again. Reconstrction Problem: The parallel change of specific assets deried from the same generic asset can lead to specific assets that are not reconstrctible. Figre 2 shows an example, where two specific assets and are changed at the same time and these changes are then reintegrated into the original generic asset at different points in time (e.g., before ). This implies that the changed specific asset can not be reconstrcted from any of the three generic asset ersions becase in ersion 1 and ersion 2 the part, and and omponent omponent in omponent Version3 Version 3 Reconstrction isn t possible omponent in Figre 1: onsistency Problem Figre 2: Reconstrction Problem

4 in ersion 3 the part are missing. Set Problem: The simltaneos change of common parts of specific asset ariants deried from the same generic asset is impossible or hard to achiee. s in the traditional M only allow working with one instance of the prodct line in parallel. This is becase each instance is treated as a certain ariant of the prodct line instead of handling all its ariants as a set. Frthermore, the identification and selection of common parts is not spported by traditional M systems. Figre 3 illstrates the problem and a possible soltion throgh a respectie specification of the affected asset parts with an example. Propagation Problem: Traditional M systems are not able to represent reisions and ariants of a prodct line in one common model. Ths, there is no possibility to propagate changes for more than one ariant at once. This is depicted in figre 4, where a change in a specific asset deried by generic asset ersion 1.0 has to be reintegrated twice, once in the generic asset ersion 1.1 and then in the generic asset ersion 2.1 of the generic asset ariant ersion Proposed M oncept for an Infrastrctre In order to oercome these problems, we propose a M concept that has the following for major properties: Set-orientation: The M concept spports maniplating consistent sets of items and configrations. For this it proides operations to identify and select them according to their properties as well as to maniplate them at once. ttribte-orientation: The M concept spports identification and selection of plain, deried and composed items that are tagged with attribtes, propagation of attribtes among the items, and design of relations among the items in order to enable attribte propagation. Unification-orientation: The M concept spports nification of an attribte model for all items of the prodct line and identification and selection schemes for assets. In the most M systems a strong identification scheme comes along with a weak selection scheme or ice ersa. For example, the selection of ariants can be realized by the preprocessor that proides a strong ariant identification mechanism ia arithmetic expressions. On the other hand, the selection of ersions throgh the conjnction of attribtes is qite complex sing that tool. In order to oercome this problem different steps are necessary: Firstly, items (configrations) and assets ( Infrastrctre) are nified. This means that they are the same entity inside of the repository (see Figre 5, Figre 6 melting). Ths, the strctral model of an asset can be sed to bild p M approaches for ersioning, change propagation and a nified selection and identification scheme sing of the repository meta model. Secondly, items and configrations in the repository are mapped on a common featre logic attribte model. Ths, the selection and identification scheme of items and configrations can now rely on the same expression model for both. Thirdly, the items (configrations) are modeled and interpreted as featres themseles. This means that additional featres decorating items (configrations) are treated in the same way as the items (configration). This way, the identification and selection scheme of items and their attribtes can be nified in one expression. Strctre-orientation: The M concept spports the definition of optional and alternatie assets and asset parts for prodct lines. Mapping of prodct line assets to M items Each prodct line asset has to hae a dal natre (figre 5): on the one hand it is handled as a M item, and, on the other hand, it flfils its prpose as a prodct line asset. To reach this goal the data strctre of each asset has to be modeled on the data strctre leel of the M repository. Ths, it will be possible to decorate each entity (figre 5) of the data strctre with featres like the ones in featre logic ([5]). There, a featre is not only the decoration of an entity bt also the entity itself. Een the changes of an entity can be.0.0 omponent.1.1 dapt component Figre 3: Set Problem Figre 4: Propagation Problem

5 seen as a featre, enabling the nification of ariants and reisions in one common model. Ths, prodct line assets and M items can be modeled and treated on the same leel. dantages of the proposed concept The proposed M concept soles the problems listed in section 4: onsistency Problem: The set-orientation and the strctre-orientation allow to define sets of specific assets. That allows to change dependent parts of different specific assets deried from the same generic asset in parallel. Reconstrction Problem: The attribte-orientation allows to nify parts of different reisions that were deeloped in parallel into one common configration item. Therefore, the reconstrction of certain specific assets created dring deelopment is always possible. Set Problem: The set-orientation allows to define sbsets of arbitrary parts of specific assets deried from generic assets. s to these sets affect all selected assets at the same time. Propagation Problem: Set and attribte-orientation enable to grop parts of different ariants of specific assets that were deeloped in parallel into a common set and to change them at one time. This makes mltiple reintegration sperflos. The realization of sch an infrastrctre reqires anchoring the prodct line asset and configration models in a ersion-set-oriented repository ([6]). This is necessary to interpret a certain M item as a set of different ariants depending on the properties on the data strctre leel, as mst be done for generic prodct line assets. dditionally, it is necessary to explicitly express the relations among different assets. This will be done by the featre logic approach (see [5]) based on the prodct line assets data strctre. This allows to design the dependencies and attribtation on a finer grained leel than with traditional M concepts. 6 onclsion In this paper we present a new concept for configration management to spport management of software prodct line assets. Typical problems of traditional approaches in a prodct line context are described and their soltion sing the new concept is sketched. Ftre work will coer the refinement and, later on, the implementation of the concept sing existing tools (if possible). REFERENES [1] K.. Kang, S.G. ohen, W.E. Noak,.S. Peterson, Featre-Oriented Domain nalysis (FOD) Feasibility Stdy, Tech. Report MU/SEI-90-TR-21, Software Engineering Institte (SEI), Noember 1990 [2] K. zarnecki, U.W. Eisenecker, Generatie Programming, ddison-wesley, May 2000 [3] D.M. Weiss, Defining Families: The ommonality nalysis, Lcent Technologies ell Laboratories, 1997 [4]. tkinson, J. ayer and D. Mthig, omponent-ased Prodct Line Deelopment: The Kobr pproach, 1st International Software Prodct Line onference, Pittsbrgh, gst [5]. eller, onfigration Management with Version Sets, Unified Software Versioning Model and its pplications, PhD thesis, papers/zeller-phd [6]. Reichenberger, Konzepte nd Verfahren für die Software-Versionserwaltng, Uniersitätserlag Rdolf Traner, Linz 1994 M Item melting = M Item Infrastrctre 1 2 melting Infrastrctre = 1 E 1 E 2 E 3 E 4 2 E 7 E 8 E E 9 E 10 E 5 E 6 E 12 strctring strctring = M Item = M Item = M Item Infrastrctre = F 1 F featring 1 2 featring E 1 E 2 E 7 E 3 E 4 E 8 E 11 E 1 : ( F 1 : x : r ) :s E 2 : ( : r : ) ( : t : ) : ( F 1 : x : ) ( F 1 :y : ) 2 : ( : r : ) : t 3 E 5 E 6 4 E 9 E 10 E 12 Figre 5: Featre Set Items Figre 6: Featre Set onfigrations