Transcription
Change Management: Modeling Software Product Lines EvolutionSamuel A. Ajila, Ph.D. MIEEEDepartment of Systems & Computer Engineering, Carleton University,1125 Colonel By Drive, Ottawa, Ontario, K1S 5B6, Canada, ajila@sce.carleton.caAbstractIn a traditional software engineering approach (otherwiseknown as single-product approach), the softwarearchitecture is evaluated with respect to the requirementsof that product alone. However, a product line approachrequires the software designer to consider requirements fora family of systems and the relationships between thoserequirements. This paper examines three kinds of evolutionprocesses: architecture, component, and product. Inmodeling software product lines evolution, four distinctchange management processes are identified – productchange process, component-set change process, frameworkchange process, and product line change integration.These change processes share four strategies – changeidentification, change impact calculation, changepropagation, and change validation. This paper alsopresent an evolution modeling approach based on thedependency relationships structure of the various artifactsinvolved in product line families. The paper also showshow the relationships between the different artifacts in aproduct line is captured and used in change management.1.IntroductionA software product is the result of a set of activities, whichappeal to various competence and knowledge. Each activitymanipulates different kinds of artifacts (requirements,design, coding, testing, etc.) [1, 2]. Software product maybe changed in order to introduce new user requirements, tocorrect errors in the requirements specification or design,and to introduce new machine or new environment.Evolution comes into play because of these changes. Ingeneral, change management is necessary because ofsoftware evolution. The main defy in change managementactivity is to ensure the consistency of all the assets withina product line. The result of software evolution is to satisfythe need of users as well as the product development team[1, 3].A software product line [4, 7, 10] is a group of softwaresystems sharing a common (not identical), managed set offeatures that satisfy a well defined set of needs (market,special mission or otherwise) and that are developed from aset of common core assets for a specific applicationdomain. It is an “intermediate” level of reuse wherecomponents are used for subsequent product versions andfor a family of software products. Modeling product linesprovides substantial reuse advantages. The benefits of reuseincludes [7, 10] – reduce time to market, reduce productdevelopment costs, improved process predictability,increased product quality, achieve large-scale productivitygains, and increase customer satisfaction. The individualevolution of a product in a software product line is affectedby the evolution of the reuse components as well as theevolution of the rest of the assets involved in the productline architecture [4]. In traditional software engineering(single product), a sizable amount of money and time is spentdoing software product evolution. This is so because of thecomplicity involved in the maintenance of software. Forsoftware product lines, the evolution of assets in the productline is even more complex compared to the traditionalapproach. The reason is that most assets depend on multiplesoftware systems [10].This paper examines the problems associated with product lineevolution, identifies four distinct change managementprocesses in relation to product lines, and proposes a model forproduct line evolution.The rest of this paper is organized as follows. Section 2presents software product lines evolution. Section 3 discussesthe change management processes. Section 4 presents amodeling approach to software product evolution and aconclusion is given in section 5.2.The problem - Software Product LinesEvolutionIn general, software evolution is a change process that coversall the life cycle of a software product. This may be caused bychanges to requirements definition, functional specification anddesign, performance specification, system’s environment, andproduct implementation. Software product lines evolution ismore complex than the traditional software product evolution,because most assets are relied upon by the multiple products [4,9]. The dependency between the various assets in a productline is very complex due to the multiple artifacts involved andit may be difficult to maintain the status of the assets. Productsin software product line are normally built for use by thecustomers and the use, in general, will lead to newrequirements. New requirements may also emerge from theintroduction of new technology or new environment. Thesenew requirements change can affect both system functions aswell as business goals on which the product is developed.There are two things to be done when a new set ofrequirements emerge: the first one is a business decision – is whether therequirements should be incorporated into the existingproduct or whether a new product should bedeveloped, and the second is technical – if the decision is toincorporate the new requirements then what are theeffects (consequences) of these new requirementschange on the product, the product line architecture,the product line requirements, and the assets set. Ifthe effects are limited to the product itself, theevolution is handled in the usual way as in traditionalsoftware development. If the effects span beyond theproduct to other artifacts then the evolution is morecomplex because of the inter- and intra-relationshipsbetween the various artifacts. The discussion in thispaper is centered on the technical aspect.
Architecture EvolutionComponent EvolutionProduct EvolutionorNew ProductSoftware Product LineChange Management ProcessesArtifacts (SPLA)changeProduct Change ManagementComponent Change ManagementFramework Change ManagementProduct-line Change IntegrationAdaptive ChangesPerfective ChangesCorrective ChangesPreventive (anticipative)changesmay be decided that a subset of a standard will besupported. The standard is upgraded in subsequentreleases of the product. When a change occurswithin a product, the change is propagated to otherassets within the product in order to ensureconsistency.New Version Component change Management – a newproduct may be introduced in order to support newfunctionality or to support an old functionality in adifferent way. This may be because of newhardware platform or new quality requirements.This can be achieved by adding a new domainspecific component or by replacing an oldcomponent with a new one that will implement theadditional functionality in a better way. When thisoccurs, the change is propagated within thecomponent set of the product in order to assureconsistency and maintain high quality. Framework change management - Acompany may decide to release a new set ofproducts into the market based on an existingproduct line but this set is different in some aspects(product behavior, quality, etc.). In this case, thedifferences (in terms of behavior or quality) willaffect many assets within the framework.Therefore, the changes generated are propagated toother assets within the framework to maintainconsistency.Change ProcessesChange IdentificationChange ImpactChange PropagationChange ValidationFigure 1.0 – Software Product Line EvolutionWhen the effects of change requests in the context of a product line gobeyond the product itself to the other assets then we need to look at threedifferent kinds of evolution – architecture, component, and product (cf.figure 1.0). The first major asset of the product line is the architecture.The main activity is to design an architecture that covers all the productsincluding features that shear the products. The second set of artifacts isthe components that have been clearly identified in the product line architecture. The third set comprises the products developed based on thearchitecture and the components. Therefore, any change to any part ofthese assets must be well managed in order to preserve the consistency ofthe assets base.3.Change managementChange management is necessary because of software evolution. In thiswork, we identify four different types of changes that may affect softwareproduct line artifacts [1, 2] (cf. figure 1.0): adaptive changes – these kinds of changes deal with newenvironmental or technological requirements such as newsupport system or new machine. perfective changes – these deal with new performancerequirements in order to enhance the quality of the products;improve functionality and changes to the business model.Perfective changes may be employed in order to introduce a newproduct (or a new version) into the market. corrective changes – diagnose and correct errors inspecification, design, and development of the product or reactionto the apparition of errors in a particular product due to customercomplaints. preventive (anticipative) changes – anticipate future changesand try to correct them in order to avoid major modification ofthe system.In addition, four distinct change management processes are identified (cf.figure 1.0):Product change management – a product is changed by addingnew features or by extending the functionality of a product in order tosupport fully a standard. In some cases when a product is first released, itProduct line change integration – When anew product line is introduced into the softwareproduct line, changes within the software productline are propagated to all the product lines andintegrated into the existing products generatedfrom the product line architecture.The change management processes aboveshare a set of sub-activities based on the changeprocess strategies below (cf. figure 1.0): Change identification – Identifies thechanges to be made, determines the changetype, and updates the history of changes. Todo this, we need answers to the followingquestions:oo What is the definition of thechange?What is the history of the change?(That is, what are the decisions thatled to the change?)Change impact – analyze the changetype, calculate the impact of change onthe affected parts using dependencyrelationships, and determine furtherchanges that may be generated due tothe impact. In effect, we need to answerthe following questions:o What is the impact of thechange on the product lineartifacts?
o What is the execution pattern of the change?Change Propagation – propagate the effects of thechange in the product line assets in order to ensureconsistency within the assets base. That is,o In what way is the change going to becarried out?o Who is going to carry out the change? Change validation – to ensure consistency, thechange must be validated.o It must be assured that all the needs forthe change are satisfied.o The change must be carried out inaccordance with the specification.o Determine the parts of the frameworkthat may need to be regression testedafter the change.A valid product line change is complete if [3]: We can identify all other assets (i.e. victims ofchange) affected by the change; We can measure the consequences (i.e. impacts) ofthe change on these “victims”; We can trace the relationships between the changedasset and the rest of the product line families; and We can acquire knowledge on how to perform andmanage the change. AnalysisAnalysis represents specifications based on requirements.Using objects orientation and UML notations [5, 6], analysismodel of a product consists of use case diagram, sequencediagram, class diagram, and state chart based on analysisobject (figure 4.1a). The design model consists of sequencediagram, design class diagram, design objects, subsystemdecomposition, and deployment diagram (figure 4.1b). Theimplementation implements an executable product based onthe design specification.1Class Diagram11.*Analysis ObjectState Chart11Analysis Model1Figure 4.1(a) – Analysis ArtifactsaiIntrarelationshipDesignSequence DiagramDesign Class Diagram1.* 11.*d21.*1di1 1InterrelationshipImplementationi11.*1Design Objects111.*Design ModelSubsystem Decomposistiondji2iji6Figure 4.0 – Product life cycle phases4.11.*1Use Case Diagramajd111.*Sequence Diagram1a3a1The relationships between the artifacts within a life cyclephase are referred to as intra-relationships and those betweenthe phases are called inter-relationships.The interrelationships allow vertical traceability while the intrarelationships allow horizontal traceability. A product lifecycle consists of analysis, design, and implementation.Modeling Software Product Line EvolutionIn this section, we present a modeling technique for softwareproduct line evolution. We start by defining a product lifecycle and using dependency graph to show the relationshipsbetween the different assets within a product (figure 4.0).11Deployment DiagramFigure 4.1(b) – Design ArtifactsWe view each product in the product line as a twodimensional plane consisting of a set of horizontaltraceability and a set of vertical traceability (figure 4.0). Theproducts are related to one another because of the sharedcommon assets (figure 4.2).
impact analysis function and the propagationprocess; and gives assistance to the user bychecking the consistency of the bases as well asrecording the history of change.ProductLineRequirements Software Product Lines – This consists ofproducts, component set, product-line architecture,the set of core assets in the product line, and therelationships between them. Core Assets Base – This base consists of all thecore assets, their properties, and historical factors(attached to each of the asset in case of reuse). Inthe base, all the assets have uniform representationin order to facilitate their interpretation andevolution. Dependency-Structure-list Base – This baseconsist of all the artifacts involved in the productline families and their relationships. These includeproduct line architecture, component-set, andproduct-lines. It consists of a database of all theobjects, a fact base of all the direct dependencyrelations, and a knowledge base containing predefined indirect relations and integrity constraints.The base is persistent because each “entity” has aunique internal identification. Change Management Tool – The changemanagement tool is based on a model called“What-If” [1, 2]. What-If evaluates à priori theimpact of object change in a software system. Themodel is generic and it covers the entire productlife cycle. It is based on a “mixed software views”approach. In this approach, object change isexplained in terms of life cycle view, combinationof life cycle phases (sub-views), and the domainspecific view. The domain specific view allows thespecification of fine grain objects and the life cycleview allows the specification of medium and largegrain granularities. Impact analysis is à priori inWhat-If model, which means that one can calculatethe effects of a change before it is even carried out.This is particularly useful because if a newrequirement is going to cost too much in terms ofmanaging the changes that it is introduced into theproduct line, then, it is better to develop a newproduct line and treat the requirement as variability.Product Line ArchitectureComponentSetA productProductRequirementsProductLineA product life cycle phaseFigure 4.2 – Evolution of software product lineThere are relationships between the product linearchitecture and the product line, and between the componentset and the product line. Using the dependency relationships,we build a set of dependency structures as follow [8]:DEPENDENCY-STRUCTURE-list t}PRODUCT-LINE-DEPENDENCY-list , Product-Dependency-listn}PRODUCT-DEPENDENCY-list {Intra-Dependencies,Inter-Dependencies}The DEPENDENCY-STRUCTURE-list is then used tocalculate the impact of change and propagation. TheSoftware Product Line Evolution Process consists of thefollowing (figure 4.3): Change Process Manager – The process managersets the goals, regulates the change process, andhandles all the dynamics of the effects of change.This includes activating the necessary operationsbased on the type of change and the consequences;verifies constraints attached to the execution of5.ConclusionIn traditional software engineering, a sizable amount ofmoney and time is spent doing software product evolution.This is so because of the complicity involved in themaintenance of software. For software product lines, theevolution of assets in the product line is even more complexcompared to the traditional approach. This is so becausemost assets depend on multiple software systems. In addition,multiple organization units and business models are involved,and these contribute to the complexity. In this paper, wehave presented a modeling approach that will enhance theproduct-line evolution management.The changemanagement activity encompasses the dynamics involved inhandling changes and the effects on the product line families.
Our approach in this paper will aid both the developers aswell as decision makers to handle changes effectively byFigure 4.0 - Software Product Line Evolution ProcessChange RequestsI/OChange Process ManagerControlsSoftware Product LinesMaintainsChange Management ToolUsesUsesCore Assets BaseDependency-Structure-List BaseProduct life cycle wMixed-views approachFigure 4. 3 – Product Line Evolution Modelbeen able to calculate the impacts and propagate the effectsof the changes. In addition, the approach in this paper willreduce substantially the cost of products maintenance. Thisis in line with the main goal of product line engineeringwhich is, to reduce cost and increase customer satisfaction.Our approach in this paper did not include how to handleevolution when there is reuse.Domainspecific view
Bibliography[1]Samuel A. Ajila, Software Maintenance : AnApproach to impact Analysis of Objects Change,In International Journal of Software - Practice andExperience, Vol. 25(10) , pp. 1155 – 1181, October1995[2]S. A. Ajila, ‘Dealing with Impact Analysis ofObjects Change in a Distributed Team-BasedSoftware Development: Basic Concepts andPerspectives’, In Process support for DistributedTeam-based Software Development (PDTSD’99)in collaboration with 3rd World MulticonferenceSCI’99 & ISAS’99, Vol. 2, 531 – 536, July 31 –August 4, 1999, Orlando, Florida, USA.[3]S. A. Ajila, ‘Specification of Dependency Relationsin Software Change Management’, In Proceedingsof Software Development Theory, Practice andExperience – Issues and Challenges for the 21stCentury, University of Botswana in collaborationwith UNU- International Institute for SoftwareTechnology, pg 48-61, September 2000, Gaborone,Botswana.[4]Jan Bosch, Design & Use of SoftwareArchitectures – Adopting and evolving a productline approach, Addison-Wesley, 2000.[5]Bernd Bruege and Allen H Dutoit, Object-OrientedSoftware Engineering – Conquering Complex andChange Systems, Prentice Hall, 2000.[6]Grady Booch et al., The Unified ModelingLanguage User Guide, Addison-Wesley, 1999.[7]Paul Clements and Linda Northrop, SoftwareProduct Lines – Practices and Patterns, AddisonWesley, 2002.[8]A Kaba, ‘Des mécanismes pour l’évolution desproceédé de développment de logiciels, Ph.D.thesis, Département de formation Doctrale enInformatic, Centre de Recherche en Informatic deNancy (CRIN-CNRS now LORIA-CNRS), InstitutNational Polytechnique de Lorraine, Nancy,France, July 1996.[9]M. M. Lehman and L. A. Belady, ‘Programevolution: Process of software change. APICStudies in Data Processing No 27, 1985, AcademicPress.[10]Stephen R. Schach and Amir ion in Product Lines, In Software ProductLines – Experience and Research Directions,Edited by Patrick Donohoe, Proceedings of the 1stSoftware Product Lines Conference (SPLC1), pg437-450, August 28-31, 2000, Denver, Colorado,USA.
requires the software designer to consider requirements for a family of systems and the relationships between those requirements. This paper examines three kinds of evolution processes: architecture, component, and product. In modeling software product lines evolution, four distinct change management processes are identified - product
![Change Management Process For [Project Name] - West Virginia](/img/32/change-20management-20process-2003-2022-202012.jpg)
