Separating Variability Concerns in a Product LineRe-Engineering Project

A. Hubaux, P. HeymansPReCISE Research Centre

Faculty of Computer ScienceUniversity of Namur

{ahu, phe}@info.fundp.ac.be

H. UnphonSoftware Development GroupIT University of Copenhagen

unphon@itu.dk

ABSTRACTFeature diagrams have now become common variability mod-els in software product lines engineering literature. Whereasongoing research keeps improving their expressiveness, for-malisation, and automation, open studies of their usage inreal projects are still missing. This paper intends to (1)present the process we followed to elicit the variability ofPloneMeeting, an Open Source project, and (2) report onthe initial results obtained when applying variability mod-elling techniques promoting separation of concerns betweensoftware variability and product line variability.

Categories and Subject DescriptorsD.2.1 [Software Engineering]: Requirements—Elicitationmethods, Methodologies, Tools, Languages ; D.2.13 [SoftwareEngineering]: Reusable Software—Domain engineering

General TermsDocumentation, Experimentation, Languages

KeywordsSoftware Product Lines, Open source, Variability Manage-ment, Variability Model, Feature Diagram, Separation ofConcerns

1. INTRODUCTIONAdapting the definitions in [6], we call “a set of software-

intensive systems that share a common, managed set of fea-tures satisfying the specific needs of a particular market seg-ment or mission” a product family (PF). If those systems arein addition “developed from a common set of core assets ina prescribed way”, we call them a (software) product line((S)PL). SPL Engineering (SPLE) is a software engineeringparadigm that institutionalises reuse throughout softwaredevelopment. By adopting SPLE, one expects to benefitfrom economies of scale and thereby improve the cost but

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.EA-AOSD ’08, March 31, 2008, Brussels, BelgiumCopyright 2008 ACM 1-60558-143-9/08/03 ...$5.00.

also the productivity, time to market, and quality of devel-oping software.

One of the main ideas behind SPLE is to dedicate a spe-cific process, named Domain Engineering, to the develop-ment of reusable artifacts, a.k.a core assets. These core as-sets are then reused extensively during the development offinal products, that is Application Engineering.

Central to the SPLE paradigm is the modelling and man-agement of variability, i.e. the differences between the mem-bers of the SPL. The concept of variability will be clarified inSec. 2 . In order to tackle the complexity of variability man-agement, a number of supporting modelling languages havebeen proposed. At the requirements level, an increasinglypopular family of notations is the one of Feature Diagrams(FD). FDs are mostly used to model the variability of ap-plication “features” at a relatively high level of granularity.They offer constructs to capture commonalities and vari-abilities, and to represent dependencies between features.Ultimately, they serve to determine the combinations of fea-tures that are allowed and disallowed in the SPL, and thusdrive product configuration/derivation.

FD languages come in various flavours, a large part ofwhich have been surveyed and formalized in [16]. In this pa-per we use the FD dialect proposed by Czarnecki et al. [9].Fig. 3 shows two examples of FD. In this section, we onlyuse the upper one. As shown, an FD is (most often) a tree,whose nodes represent features and edges represent decom-position relationships between them. Typically, decomposi-tion operators are boolean functions: and, or, xor. . . However,in [9], these are subsumed by the more general cardinalityoperator <m..n>. In the upper part of Fig. 3, feature Trans-lations is mandatory (filled circle on top) and <1..1>, meansthat at least and at most one language can be selected.

Although theoretical evaluations of FD languages exist[17], to the best of our knowledge, thorough empirical vali-dations of feature modelling techniques are still unavailable,which might be explained to some extent by the risk of dis-closing highly sensitive corporate information. Indeed, a va-riability model can reveal a substantial part of a company’sproduct development strategy. This drove us to look for asignificant and open case study allowing the free dissemina-tion of our results in the research community. PloneGov,an open source project aiming at creating a Plone platformpromoting the development of eGovernment applications,caught our attention. An overview of it can be found in [10].

More precisely, we are currently busy with the first step ofour three-step variability re-engineering process [5] intend-ing to build a comprehensive configurator of PloneMeeting,

a PloneGov Belgian product. Step 1 focuses on reverse engi-neering the variability model of PloneMeeting. The refactor-ing of the variability model will be achieved through anal-ysis and validation by the stakeholders in step 2. Duringstep 3, the new or altered design elements will be imple-mented through forward engineering. In pursuing step 1, itquickly became apparent that both the developers and theresearchers were missing a clear and agreed upon view ofthe variability currently supported by the existing software,what we call software variability (as opposed to product line(PL) variability [13]). We thus started to elicit the soft-ware variability from the existing artefacts. We will use itas a basis to confront current feature modelling techniques,and identify their limitations. The present paper reports onsome preliminary results of our reverse engineering processand states the major problems we faced.

The remainder of this paper is organised as follows. Sec. 2will recall the variability modelling approach we are adopt-ing, which is based on separating variability concerns. Sec. 3will present PloneGov, PloneMeeting, delineate the researchcontext of this case study, and state the research question.Sec. 4 will describe our information collection process andset forth our progress. Sec. 5 will put forward how the appli-cation of the aforementioned variability modelling approachis applied. Sec. 6 and Sec. 7 will respectively report on thelessons learned and limitations of the study. Sec. 8 will drawfuture lines of research and conclude this paper.

2. SEPARATION OF CONCERNSThe engineering of complex software systems entails deal-

ing with a quantity of crosscutting concerns [20]. Theseconcerns are often entangled and add to the complexity ofthe tasks. Aspect-oriented software development has pro-moted an understanding of the separation of concerns prin-ciple explicitly separating and specifying types of concerns,i.e. aspects, crosscutting the software system. Reusing as-pects requires the systematic identification and exploitationof commonality across related aspect specifications [3]. Inthe software reuse community, domain analysis is a well-known process for identifying, capturing, and organizing do-main knowledge with the purpose of making it reusable whencreating new systems. The result of this process is a domainmodel that is formed through a commonality and variabilityanalysis of the concepts in the domain [2]. We observed thatin SPLE two early concerns were often mixed in variabilitymodels [13]: Software variability and PL variability. In thefollowing paragraph, we recall these two concepts and out-line an approach we proposed previously [13] to deal withthose concerns.

Software variability refers to the “ability of a softwaresystem or artefact to be efficiently extended, changed, cus-tomized or configured for use in a particular context” [19].This kind of variability is well known from the developmentof single systems. As examples, an abstract Java super-classallows different specializations to be used where the super-class is used, an interface allows different implementationsto be chosen, etc.

PL variability [8, 14, 12], on the other hand, is specificto SPLE and describes the variation between the systemsthat belong to a PL in terms of properties and qualities, likefeatures that are provided or requirements that are fulfilled.It is important to understand that defining PL variability isan explicit decision of product management (see [12, 14]).

As an example, product management might have decidedthat the mobile phones of their PL should either offer theGSM or the UMTS protocol.

A challenging task in SPLE is to map the PL variabilityto software variability. This means that the reusable arte-facts (or core assets, which constitute the PL platform [14])should be constructed flexibly enough to allow for efficientand effective building of those systems [11, 15]. The deci-sions to be made are crucial and mutually influence eachother: which systems to offer as part of the PL (i.e., whatthe scope of the PL should be [15]), and how to design thereusable artefacts to support this scope [12].

A lack of flexibility in the reusable artefacts, or a scopethat lacks awareness of the technical realizability, can severelyundermine the SPLE process. At best, time-consuming andexpensive changes of the reusable artefacts or the scope willbe required. Therefore, it is essential to ensure that PLvariability and software variability are consistent from thebeginning. But since all changes cannot be anticipated, co-evolution of both variabilities over time should be facilitatedtoo.

In a previous paper [13], we introduced language and toolsupport for these tasks. To disambiguate the documenta-tion of variability, we propose to record PL variability andsoftware variability in separate models and to interrelatethem. We used FDs and Orthogonal Variability Models(OVM)[14] respectively, but this could have well been doneonly with FDs, as done in this paper. Equipped with formalsyntax and semantics, those models are amenable to auto-matic analysis in isolation. But, most importantly, since thecross-links (X-links) between them are also formalized, themodels can be cross-checked. We devised a set of checksthat are straightforward for the stakeholders to interpret,like whether all planned systems of the PL can be realized,or whether the flexibility of the reusable artefacts is useful.A prototype relying on a SAT solver was also implemented.

In this paper, we report on the first observations we gath-ered trying to elicit and model the PL and software varia-bility for PloneMeeting. The early results of this problemstatement leave out the testing of the automated tool sup-port, which we will address in future work .

3. CASE STUDY PRESENTATIONPloneMeeting is part of the PloneGov international Open

Source (OS) project intending to promote secure, collabo-rative, and evolutive eGovernment web applications. ThisBelgian government-initiated project offers advanced meet-ing management functionalities to national authorities. It iscurrently gaining worldwide recognition, and is being testedin some French, Spanish, and North American towns. Thefollowing subsections will introduce PloneGov, PloneMeet-ing, and the research context.

3.1 The PloneGov projectPloneGov is based on Zope and Plone. Zope is an OS

application server for building content management systems,intranets, portals, and custom applications. Zope is widelyused in the OS community. Plone is a portal and contentmanagement system (CMS) built on top of Zope.

The PloneGov project gathers around 55 European, Northand South American, and African public organizations into17 projects with more than 10 product releases [1]. Productsare divided into (1) citizen-oriented services, (2) government

internal applications such as PloneMeeting, and (3) generalpurpose tools. PloneGov fosters cooperative development ofapplications and web sites targeted to public organizationsand their citizens. More precisely, the goals of this projectare mainly to promote collaboration between public organ-isations and Small and Medium Enterprises (SME), ensuremastery of code by public servants, and benefit from producteconomies of scale.

The worldwide scope of PloneGov yields many contextsto deal with. For instance, specific legal, social, political orlinguistic aspects will constrain the features required froma given product. Hence, the need for flexibility regardingproduct derivation.

3.2 The PloneMeeting productPloneMeeting is a PloneGov product intended to manage

local and regional authorities’ official meetings. It startedin June 2007 and a working version is now available on thePloneGov site.1 Five developers are working part time onPloneMeeting. The amount of users for a product instanceis currently estimated to 100 with less than 10 different usercategories, e.g. meeting manager and reviewer. Similarlyto PloneGov, PloneMeeting is subject to many constraintsdetermined by the use localisation. For example, the dis-play language, scheduling workflows or appearance must betailored accordingly.

Arguably PloneGov, and specifically the PloneMeetingproduct family (PF), call for a way of managing variability.According to the Plone terminology, PloneMeeting is a prod-uct, which is not to be confused with the product or memberconcept of PF. Plone-specific terminology will be italicisedin the remainder of this paper to avoid misinterpretations.Two sub-products of the PloneMeeting PF, called profilesin Plone, are PloneMeetingCommunes2 and EGW. Theseprofiles need to be further refined in configurations to allowthe full specification of a running instance, i.e. a PF mem-ber. Fig. 1 sketches this situation and shows that variationpoints are likely to be present at different specification lev-els, suggesting a complex variability resolution process. Theright-hand side labels are PL related terms whereas thoseon the left-hand side are Plone related.

The different configurations currently available in the Plone-Meeting PL, are Communal Council whose goal is to handlemeetings of the communal council, Communal college aim-ing at handling meetings of the communal college, and e-gwfocusing on the meetings of the Walloon government.

3.3 Research contextThe research question addressed in the reported experi-

ment could be formulated as: What are the practical obsta-cles encountered when eliciting and reverse engineering thevariability of PloneMeeting?

In previous work [10], we introduced the idea of using SPLprinciples to engineer the PloneGov project. Our conclusionshowed a number of organisational and technical problemsthat had to be tackled. Handling the distributed developers,managing the already existing variability, and expressing dif-ferent variability levels according to the user classes are onlya few of them. We will focus here on the identification andmodelling of the variability in PloneMeeting. Since no va-riability model formerly existed, the variation points had to

1http://www.plonegov.org/products/plonemeeting2A commune is a Belgian local authority.

be reverse engineered from stakeholders and existing arti-facts to enable the re-engineering of configurable artifacts.The information sources currently used are (1) the featurerequests posted on the PloneMeeting trac3, (2) a demo ses-sion, (3) interviews with developers, (4) the PloneMeetingconfiguration menu, and (5) the Plone documentation.

The creation of Plone products follows a partially model-driven engineering (MDE) approach. For this, it resortsto UML modelling tools, mainly Poseidon and ArgoUML,and ArchGenXML to generate the Plone Python code corre-sponding to the modelled classes and statecharts. However,a proper model-based variability management approach of-fering a global view of the provided variability is still missing.The OS nature of this project could, at some point, lead toforks in the PloneMeeting code, which is a situation to beavoided to preserve economies of scale. A carefully designedvariability management tool, well integrated into the Ploneinterface, and usable in a distributed fashion is a priorityrequest from the developers.

The lack of adapted technology in this field drove Plone-Meeting developers to raise new questions regarding varia-bility management in OS distributed projects. Since theonly examples to which we applied our variability modellingapproach were very simple, this non-toy application was achallenging case to do a reality check of current modellinglanguages, and to exhibit their limitations.

The following sections will report on the early results weobtained when extracting and modelling the PL and soft-ware variability of PloneMeeting. This process kept oneresearcher busy during three months. Its main task wasto extract variation points and variants from the trac andthe PloneMeeting configuration menu. He also attendedfour coding sessions, had three meetings with developers tobetter understand their expectations and needs in variabil-ity modelling, and took part in a demonstration and feed-back session of PloneGov products to Belgian local authorityrepresentatives. PloneMeeting coding sessions gather, al-most every week, two to three developers working in a pairprogramming fashion. During these sessions, they imple-ment the feature requests or solve the bugs present on thetrac. Priorities among them are defined according to theorigin (e.g., government or commune representatives, devel-opers. . . ), and urgency of the request.

4. REQUIREMENTS AND VARIABILITYELICITATION

In order to keep track of the requirements, we resortedto OSRMT, a requirements management tool designed toachieve full software development life cycle traceability forfeatures, requirements, design, implementation, and test-ing [18]. It helped us maintain traceability links betweenthe information sources, requirements, and coarse featureswe identified. Given that our variability modelling approachis not yet supported by an editor, the FDs were designedwith a generic diagram modelling tool, namely OmniGraf-fle, to avoid the bias of another SPLE method.

The variability modelling process we followed is sketchedin Fig. 2. The first contacts we had with the developers were

3trac is a web-based software project management andbug/issue tracking system. For further informationabout the PloneMeeting trac, please consult http://dev.communesplone.org/trac/report/120

PloneMeeting

PloneMeetingCommunes EGW

e-gwCommunal

collegeCommunal

council

Product Family

Profiles

Configurations

Plone

Product Family members

Product

CMS

Web pages

is a product of

is a specialisation of

is an instance of

Figure 1: Overview of PloneMeeting variability resolution levels

Plone documentation

<script var a= var xl if(xls

Coding sessions

Meetings

Configuration menu

Demo session

Identified products

Variability models

is known from

process data flow

Requirements

trac

Variabilitymodelling

Concernanalysis

Productidentification

Requirementselicitation

Figure 2: Variability modelling process

informal meetings where the purpose and development ap-proach of their project was presented. The already existingvariability management interface, namely the configurationmenu, was also discussed there. Note that this configura-tion menu results from coding efforts and not from institu-tionalised variability management through a generic config-urator. We then attended a demonstration session of theBelgian PloneGov products and three coding sessions dur-ing which the trac and Plone documentation were broughtto our attention.

From the demo session we learned that PloneGov eGov-ernment products tend to create many needs that users,e.g. commune representatives, citizens. . . , were not aware

of initially, making it tough to eliciting requirements. Thedevelopers follow a prototyping approach to elicit new re-quirements or adapt older ones. More precisely, web pagesare generated with a likely content and presented to a set ofrepresentative stakeholders who are requested to commenton them. Requirements are then documented and updatedaccordingly. PloneMeeting is derived from the College prod-uct, which was originally targeted to communes only, anddetermined the PloneMeetingCommunes profile. The EGWprofile has been defined according to the previously exist-ing EGW web site. An important part of PloneMeetingrequirements has thus been implicitly brought in by the de-velopers who took over its development. Meetings with thedevelopers and attendance to coding sessions were needed toidentify this tacit knowledge, to retrieve the PloneMeetinggoals, and to analyse the tasks at hand. A lot of work stillneeds to be done here as we first focused on the textual infor-mation available (as opposed to direct contact, e.g., throughinterviews).

Since the very beginning of the project (that is prior toour study), the PloneMeeting trac tracks all the release in-formation, changelogs, bugs, and trac requests. Extractingrequirements from trac requests is a tedious process sincethey must be separated from bugs, code improvements, andre-factoring requests. A problem is also that new trac entriesare frequently added. Trac requests stem from the develop-ers’ needs, anticipation of stakeholders’ expectations, anduser feedback on demos. Every trac request is now stored inOSRMT as one or more requirements. Features are then ex-tracted from requirements, and saved into OSRMT in a dedi-cated item category. In order to trace decisions, traceabilitylinks between the information sources (another item cate-gory in OSRMT), the requirements and the features havebeen systematically added. Being abstracted from require-ments, as also done by other authors [4], our features arerather coarse-grained, which often makes it difficult to sep-arate the common from the variable parts of the PF.

The configuration menu of PloneMeeting is pre-configuredaccording to the loaded profile, and enables the definition

of configurations as shown in Fig. 1. Much variability hasbeen extracted from the configuration menu since it exhibitsthe software commonalities and variabilities. Nevertheless,each of the abstraction layers, i.e. Plone, Zope, and Python,comes with its own commonalities and variabilities whichare intricate to identify without a deep understanding andknowledge of their inner working. Consequently, we re-stricted the scope of our first variability model to Plone-Meeting, only targeting the variability mechanisms of Ploneit deals with directly. The Plone documentation was here ofgreat help to understand their intertwinings.

5. APPLYING SEPARATION OFCONCERNS

This section will report on and picture our application ofseparation of concerns (SoC) to variability modelling andhighlight the major difficulties we encountered up to thispoint. First, we will show how the PL and software concernscan be suitable for variability modelling and identificationof mismatches. Secondly, we will put forward how these twoconcerns called for further refinements

5.1 Mapping PL and software variabilityThe growing recognition and internationalisation of Plone-

Meeting is gradually bringing its lot of new requirements.For instance, the recent deployment of PloneMeeting in someSpanish towns requires pages to be displayed in Spanish.The Plone internationalisation (i18n) initiative intends toprovide a flexible mechanism to manage language selectionand display. The so-called PlacelessTranslationService (PTS)is Plone’s built-in translation management service. It pro-vides a dynamic translation mechanism independent fromstring locations in web pages, and notably enables the cre-ation of domain-based translations [7]. New domains, suchas PloneMeeting, can be automatically added at product in-stallation and extend the translations of Plone for the newcontents they provide. Since PloneMeeting is being used inthe French-speaking part of Belgium, France, the USA, andSpain, the three languages required by the stakeholders areFrench, English and Spanish. However, the languages cur-rently provided by PloneMeeting are only French and En-glish.

Arguably, the required and provided languages are notequivalent since Spanish is required but not available inPloneMeeting. This kind of discrepancy prevents softwareproducts to meet the stakeholders’ expectations. Even thoughidentifying them in this example is trivial, tracking all pos-sible mismatches in the whole SPL, is an overly challengingtask. The approach recalled in Sec. 2 is a possible solutionto this issue as it allows separating modelling concerns andestablishing a mapping between the PL and the software va-riability. The PL variability of our example is presented inthe upper part of Fig. 3. Since only fr (French) and en (En-glish) translations are available at the PloneMeeting level,we added a “virtual” feature es (Spanish) surrounded by adashed boxed as appearing in the lower part of Fig. 3. Themapping between the PL and software variability is depictedby bold grey arrows, called X-links. It is through this in-cremental mapping that mismatches between the required(PL) and provided (software) variability can be established,hence allowing conflict resolution planning.

5.2 Domain variability: an emerging concern

PloneMeeting

i18n

Translations

fr esen

PL variability

Software variability

<1..1>

<1..1>

X-link

PloneMeeting

Translations

SpanishFrench English

Figure 3: PL to software variability mapping exam-ple

Are the PL and software concerns the only relevant mod-elling perspectives? Our experience tells otherwise. A cur-rently neglected aspect of the PTS is that the pages’ lan-guage is automatically determined by the web browser. Mod-ern browsers like Firefox enable the run-time selection of thedisplay language, e.g. English (en), but also its variants,i.e. en-au (Australia), en-ca (Canada) or en-us (USA). Letus assume the browser is set to en-ca. Because this labelis not available in PloneMeeting, the fallback mechanism4

will select English since it is the default language, and onlythe picky user will spot the wrong English version is beingused. Suppose now the user wants pages to be displayedin French, fr, or even fr-be (Belgium), fr-ca (Canada) orfr-fr (France). What will the system behaviour be if thenon standard fr, let us say fr-be, is chosen? Since no fr-be

is present at the software level, the default language will beselected even though a French version exists, which is notsatisfying. Unsurprisingly the PTS already solves this issueby considering French and all its extensions as all being thesame language family. But one can reasonably assume thatsome contexts might specifically demand the ca or us ver-sion of the language. The proper identification of possiblevariations in the domain (or environment) is thus a majorsuccess factor of software deployment and evolution.

Hence, the domain variability seems now to be a concernwe should handle separately. The reason is twofold. First, itallows focusing only on the stakeholders’ requirements whenbuilding the PL variability model. Secondly, creating a sep-arate model for the domain variability supports better reuseand helps to better identify and understand what the appli-cation domain is. Moreover, explicit separation of domainvariability further encourages model reuse in different appli-cations, and can save of lot of re-design efforts. The devel-opment of web applications is typically an area that couldbenefit from reusable domain models since browser-specific

4If enabled, the fallback mechanism, part of the PTS, au-tomatically switches to the default language if the selectedlanguage is not available.

aspects condition parts of the code. These specificities areusually known by advanced web developers but still, manydisplay issues are only discovered at run-time. Well definedweb browser domain variability would save developers un-necessary tests by more anticipated and careful design.

6. LESSONS LEARNEDThe lessons we learned from the elicitation process will

first be presented. The expected benefits and issues of apply-ing SoC to real cases will then be reviewed. The developers’expectations regarding variability modelling will finally beput forward. However, a longer and more thorough (quan-titatively and qualitatively) investigation will be needed toconfirm or refute these “first impressions”.

6.1 Elicitation

Information source management is very challenging.The multiplicity of information sources entails muchinformation filtering and calls for a proper identifica-tion of the modelling concerns a particular element isaddressing. The a posteriori classification of the in-formation sources is presented in Tab. 1. The demosession offered a nice overview of the Belgian Plone-Gov projects but provided few details. This, however,helped identifying stakeholder classes and deploymentenvironments. Meeting with the developers is the mostdifficult information source to manage because of itsfluctuating granularity. Coding sessions are focusedon very specific parts of the code and make it hardto identify proper variation points without having fullknowledge of the implementation. However, our un-derstanding of their working methodology was signifi-cantly improved through these sessions. The fact thatrequests are explicitly posted on the trac drove us toconsider them as PL variability, which later gives birthto software variability. The configuration menu is themost accurate and detailed source of software variabil-ity we came accross so far. The Plone documentation ishelping us figuring out how PloneMeeting componentsintegrate into, and interact with the Plone platform.

OS projects stimulate the research progress. Workingwith OS facilitates knowledge transfer and concept in-tegration. The major advantages of OS projects weare most appreciating are (1) the developers’ willing-ness to share information, (2) the material availability,(3) the absence of contractual constraints, and (4) theeasiness to add and test new variability managementtechniques.

Variation points must be carefully selected. We men-tioned in Sec. 4 that the complexity of Plone compelledus to restrict the scope of the elicitation to avoid con-sidering irrelevant details. Targeting the needed vari-ation points of Plone turned to be very challengingbecause (1) the actually used functionalities had to betold appart from the unused ones, and (2) the Plonespecific dependencies among the used functionalitiesthat were unnecessary to the understanding had to beignored.

6.2 Separation of concern

Readability is improved. The use of separate FDs showedthat (1) the models are less cluttered than if variabilityconcerns had to be annotated directly in the FD, and(2) the focus being on a specific concern, the elicitedelements are integrated in a known and independentcontext, i.e. PL or software.

Understandability is improved. Besides supporting bet-ter readability, SoC allows to better understand mod-els as their background are stated clearly. Indeed, onecan reasonably assume that the vocabulary and waysof thinking of PL managers and software developerscan vary, hence resulting in different models. Sincethe models are focused on a single concern, they aremore adapted to decision makers or modellers, therebysupporting the understandability of the targeted audi-ence.

Evolvability is improved. As our investigation moved on,both the PL and software variability models evolved.Keeping them separated helped us better sticking toreality by not having them implicitly influence eachother. It is during the mapping that the different viewswere confronted and mapped, thereby revealing howthe concerns actually evolved.

Missing features are identified. As we reported in Sec. 5,the mapping between the concerns enables the identifi-cation of missing features. This proved most useful toidentify the missing features of the software variability.

Appropriate granularity levels are needed. Since impl-ementation related information was mostly available,the software FD tended to be much more detailedthan the PL one. Establishing a proper mapping inthese circumstances was awkward because of the vary-ing granularity levels of the models, which left manysoftware variation points unlinked.

Validation of tacit requirements is needed. We show-ed in Tab. 1 how the information sources helped reverseengineer the variability concerns. However, some re-quirements, like the available languages, leading to themodelling of the PL variability were elicited from cod-ing sessions. Since it contradicted with our will toelicit the software and PL variability independently,we were constrained to have all the tacit requirementsvalidated by the stakeholders before being integratedinto the PL variability model.

6.3 Variability modelling

Better constraint checking is needed. During our anal-ysis of the configuration menu, we came accross someunchecked constraints. For instance, the PloneMeet-ing configuration menu enables the creation of meetingconfigurations. For any given meeting configuration,one can specify whether (s)he wants it to be defaultor not. Besides representing the default selection ofa meeting, one also expects only one default meetingbeing selected at a time, which was not the case. Thisissue raises a very sensitive question, i.e. at which levelshould property checking be performed?. If performedat the code level, future misbehaviours are most likelyavoided but inconsistencies at the configuration level

Table 1: Information source classificationSources Targeted concernsDemo session PL variabilityMeeting with developers PL, software and domain variabilityCoding session Software and domain variabilitytrac PL variabilityConfiguration menu Software variabilityPlone documentation Software variability

are not prevented, which can lead to severe confusionsfrom the stakeholder viewpoint. Conversely, doing itat the configuration level averts inconsistencies, mightlighten the business code, and increase its reusability.Constraint checking might also be needed at both lev-els for reliability reasons. Hence, modelling decisionsare to be carefully considered to avoid unexpected re-sults.

Workflow variability modelling is required. Proper va-riability modelling of behavioural aspects, namely work-flows associated to Plone objects, is becoming manda-tory to better manage the growing amount of differentworkflows, and to propose more intuitive configurationinterfaces. Workflows are currently created at designtime and adapted at coding time but cannot be modi-fied at configuration or run time, thereby reducing theoverall flexibility and reusability.

Binding FD together will be mandatory. For the mo-ment, we modelled the Plone and PloneMeeting va-riability in separate models. However, the elicitationshowed that they are both tightly bound together withina single concern. For instance, we discovered thatthe PloneMeeting translations can overwrite those ofPlone, which cannot be expressed with current FDlanguages. Expressing such constraints will becomemandatory to suitably reflect reality.

7. CURRENT LIMITATIONSGiven that our investigation is still at its early stages, the

reported lessons learned should only be considered prelimi-nary. Along these lines, there are also several other limita-tions:

Ignored variability. As we mainly resorted to the tracand configuration menu to identify variability, manyrequirements and rationales regarding variability reso-lution of previous systems might have been ignored sofar.

Lack of validation. Since our work has not been validatedby the stakeholders yet, possible biases might be presentin our results. Furthermore, the rendering and inte-gration of the variability model into the PloneMeetingconfiguration menu have not been addressed so far.This is a major endeavour that will require careful at-tention, especially since we consider it one of the mostimportant drivers for the uptake of the variability mod-elling approach by the developers.

OS possibly too specific. The OS nature of this projectmight fail attesting issues that companies developingproprietary systems are facing, or consider problems

irrelevant to them. One can think of uncontrolled cre-ation of forks in the source code or distributed varia-bility management as two likely examples.

Simplified view. The issues we raised about SoC reflectonly a simplified view of reality. The extensibilityamong Plone products entails many issues FDs are notcurrently dealing with, like the fallback mechanismswe discussed. Complex rules constraining variationpoints and variants selection need to be added to faith-fully depict reality. These might require the additionof new constructs to FDs (e.g., binding times) or com-plementary use of other languages, e.g. to describe thedynamics of runtime binding.

Inexperienced modeller. The relative lack of experienceof the appointed researcher in the field of SPL andvariability modelling could bias our results.

SoC performed on a small subset. Since we mostly fo-cused on variability elicitation, the modelling and map-ping between the concerns was performed on small sub-sets.

8. CONCLUSIONIn this paper, we reported some initial observations made

when studying PloneMeeting, an open source project cur-rently being re-engineered into a software product line. Weargued that PloneMeeting could be a valuable case study todo a reality check of current feature modelling approaches.A central goal of ours is to investigate how separation ofconcerns can help achieve more manageable and scalablefeature diagrams. Our preliminary study highlighted (1)the difficulty of eliciting the needed information from a vari-ety of partial and evolving information sources, and touchedbriefly (2) the limitation of the current approach in terms ofexpressiveness (variability in the domain, dynamic variabil-ity. . . ). Our next steps will be to pursue further elicitationand modelling of variability of PloneMeeting, to discovernew challenges or confirm/refute the existing ones. Adap-tation of current modelling techniques will follow. Thesewill then have to be formalized to allow for safe and effi-cient tool support which, in turn, will have to be evaluatedtoo. Although there are some specificities in dealing with anopen source project, we are confident that our findings willbe useful for the developers of more “conventional” productlines as well.

9. ACKNOWLEDGMENTSThis work is sponsored by the Interuniversity Attraction

Poles Programme of the Belgian State of Belgian SciencePolicy under the MoVES project.

We also want to thank EASI-WAL for welcoming us, andmore specifically Gaetan Delannay, Gauthier Bastien, andJean-Michel Abe for their availability and hearty coopera-tion.

10. REFERENCES[1] PloneGov. http://www.plonegov.org/.

[2] G. Arango. Domain analysis methods. SoftwareReusability, pages 17–49, 1994.

[3] J. Araujo, E. Baniassad, P. Clements, A. Moreira,A. Rashid, and B. Tekinerdogan. Early aspects: Thecurrent landscape. Technical ReportCMU/SEI-2005-TN-xxx, Carnegie Mellon University,2005.

[4] K. Chen, W. Zhang, H. Zhao, and H. Mei. Anapproach to constructing feature models based onrequirements clustering. In RE ’05: Proceedings of the13th IEEE International Conference on RequirementsEngineering (RE’05), pages 31–40, Washington, DC,USA, 2005. IEEE Computer Society.

[5] E. J. Chikofsky and I. Cross, J. H. Reverseengineering and design recovery: A taxonomy. IEEESoftw., 7(1):13–17, 1990.

[6] P. Clements and L. Northrop. Software Product Lines:Practices and Patterns. Addison-Wesley LongmanPublishing Co., Inc., Boston, MA, USA, 2001.

[7] C. Cooper. Building Websites with Plone: An in-depthand comprehensive guide to the Plone contentmanagement system. Packt Publishing, November2004.

[8] J. Coplien, D. Hoffman, and D. Weiss. Commonalityand variability in software engineering. IEEE Softw.,15(6):37–45, November 1998.

[9] K. Czarnecki, S. Helsen, and U. W. Eisenecker.Formalizing cardinality-based feature models and theirspecialization. Software Process: Improvement andPractice, 10(1):7–29, 2005.

[10] G. Delannay, K. Mens, P. Heymans, P.-Y. Schobbens,and J.-M. Zeippen. PloneGov as an Open SourceProduct Line. In Workshop on Open Source Softwareand Product Lines (OSSPL07), collocated with SPLC,2007.

[11] I. John, J. Lee, and D. Muthig. Separation ofvariability dimension and development dimension. In1st Int’l Workshop on Variability Modelling ofSoftware-intensive Systems, VaMoS 2007, Limerick,Ireland, January 16-18, 2007, pages 45–49. Lero, 2007.

[12] K. C. Kang, J. Lee, and P. Donohoe. Feature-orientedproject line engineering. IEEE Softw., 19(4):58–65,2002.

[13] A. Metzger, P. Heymans, K. Pohl, P.-Y. Schobbens,and G. Saval. Disambiguating the documentation ofvariability in software product lines: A separation ofconcerns, formalization and automated analysis. InI. C. S. Press, editor, Proceedings of 15th IEEEInternational Requirements Engineering Conference,2007.

[14] K. Pohl, G. Bockle, and F. J. van der Linden.Software Product Line Engineering: Foundations,Principles and Techniques. Springer-Verlag New York,Inc., Secaucus, NJ, USA, 2005.

[15] K. Schmid. A comprehensive product line scopingapproach and its validation. In 22rd Int’l Conferenceon Software Engineering, ICSE 2002, 19-25 May 2002,Orlando, Florida, USA, pages 593–603. ACM, 2002.

[16] P.-Y. Schobbens, P. Heymans, J.-C. Trigaux, andY. Bontemps. Feature Diagrams: A Survey and AFormal Semantics. In Proceedings of the 14th IEEEInternational Requirements Engineering Conference(RE’06), pages 139–148, Minneapolis, Minnesota,USA, September 2006.

[17] P.-Y. Schobbens, P. Heymans, J.-C. Trigaux, andY. Bontemps. Generic semantics of feature diagrams.Computer Networks, 51:456–479, February 2007.

[18] A. Smith and P. Spencer. OSRMT.http://sourceforge.net/projects/osrmt.

[19] M. Svahnberg, J. van Gurp, and J. Bosch. A taxonomyof variability realization techniques. Software –Practice and Experience, 35(8):705–754, 2005.

[20] P. Tarr, H. Ossher, W. Harrison, and S. M. J. Sutton.N degrees of separation: multi-dimensional separationof concerns. ICSE, 00:107, 1999.