Modeling Adaptive and Evolvable Software Product Lines Using the Variation Point Model

Slide 1:Modeling Adaptive and Evolvable Software Product Lines Using the Variation Point Model

Diana L Webber Booz Allen Hamilton 15059 Conference Center Dr Chantilly, VA 20150 703-633-3118 webber_diana@bah.com Hassan Gomaa Dept of Information and Software Engineering George Mason University Fairfax, VA 22030 hgomaa@gmu.edu Presented at the Hawaii International Conference on System Sciences Big Island, Hawaii January 7, 2004

Slide 2:Two Major Ideas

Developer of the core assets manages variability The core asset developer builds and maintains the variants used on the applications Reuser chooses between a set of variants and creates an application When a new variant is needed, the core asset developer adds the variant to the core assets. Reuser of core assets builds unique variants from the variation points Reuser has the flexibility of tailoring the core assets to his/her needs A variation point must be modeled such that the reuser has enough knowledge to build a variant The core assets developer no longer maintains every possible variant, only the variation points

Slide 3:Four Approaches

Modeling Variability Using Parameterization Variation is applied to the parameters Modeling Variability Using Information Hiding Several different versions of a component exist Modeling Variability Using Inheritance Several versions of a child component exist Modeling Variability Using Variation Points Variants are built by the reuser Variability Managed by Core Asset Developer Variants built by reuser

Slide 4:ATM Example

This ATM example is taken from the banking system case study [Gomaa 2000] The banking system case study solves a problem for a bank that has several automated teller machines. Added variation points so the design can now be used for several different banks

Slide 5:Modeling Variability Using Parameterization

Parameterization allows a reuser to change the values of the attributes in a core asset component Parameterization allows a reuser to chose from a list of predefined options on the core asset component Limitations � Reuser can not add any new functionality without changing the core asset component

Slide 6:Modeling Variability Using Parameterization - Example

populatePromptStructure (in LanguageParameter) populates the promptStructure with all the necessary prompts in the language desired.

Slide 7:Modeling Variability Using Information Hiding

Information Hiding is where several of the same components are built with the same interface but different internal functionality. Information Hiding allows a reuser to chose from a list of predefined components which relate to different functionality or features. Limitations � Reuser can not add any new functionality without adding a core asset component

Slide 8:Modeling Variability Using Information Hiding - Example

LanguagePrompt class has a standard interface which is realized for each language. LanguagePromptEnglish and LanguagePrompt Spanish can be interchanged with each other. �interface� I LanguagePrompt providePrompt (in promptType, out prompt) �subsystem� ATMClient �data abstraction� LanguagePromptEnglish �data abstraction� LanguagePromptSpanish

Slide 9:Modeling Variability Using Inheritance

Variants are specializations of other core asset components, where the subclass can extend the interface by adding new operations or over-riding existing ones Inheritance allows a reuser to chose from a list of predefined subclasses which relate to different functionality or features. Limitations � Reuser can not add any new functionality without adding a core asset subclass

Slide 10:Modeling Variability Using Inheritance - Example

LanguagePrompt class has a standard interface. The subclasses override the promptStructure populating it with the prompts in the language of choice.

Slide 11:Modeling Variability Using Variation Points

Variation Point identifies one or more locations at which the variation will occur [Jacobson 1997] Variation Point Model (VPM) is an approach to modeling variability, which builds on Jacobson�s original concept VPM also adds the mechanism of variability to the definition Core asset components contain the variation points, reusers may build unique variants for their specific application Allows the reusers to add functionality as well as choose from a selection

Slide 12:Introduction to the VPM - Four Views

Requirements view Show the variation points as part of the requirements Component variation point view Shows which components are effected by an variation point, and which ones are mandatory Static variation point view Shows the static parts of the variation point and their relationships Shows which classes and methods are involved in the variation point Dynamic variation point view Shows how to use the variation point

Slide 13:Component Variation Point View

The symbols ? ? are used to designate information supplied by the builder of variation point model. The symbols [ ] are used to designate information supplied by the reuser Each variation point starts with a vp, the third letter is either �m� or an �o� to indicate mandatory or optional.

Slide 14:Requirements and Component Variation Point View - Example

�business logic� LanguagePrompt �business logic� PINValidationTransactionManager vpoPINattempts vpoPINformat vpoLanguage vpoExpiredCard �state dependent control� ATMControl vpoExpiredCard �subsystem� ATMClient �subsystem� BankServer �user interface� CustomerInterface vpmGreeting �database wrapper� DebitCard vpoStolenCard vpoLanguage : A mechanism will be provided which allows the reuser to display the prompts in their preferred language. The default language is English.

Slide 15:Modeling Parameter Variability Using Variation Points

�data abstraction� LanguagePrompt promptStructure: stringStructure populatePromptStructure(in LanguageParameter) {variation point = vpoLanguage} providePrompt (in promptType, out prompt) �subsystem� ATMClient Variation point vpoLanguage shows the reuser to use the method populatePromptStructure (in LanguageParameter) to select the language. The only difference for parameterization is that the variation point is modeled.

Slide 16:Modeling Information Hiding Variability Using Variation Points

Variation point vpoLanguage shows the reuser to build a class that realizes the interfaces of LanguagePrompt. The variant LanguagePromptVariant is built by the reuser and contains the prompts in the language of choice by the reuser.

Slide 17:Modeling Inheritance Variability Using Variation Points

Variation point vpoExpiredCard shows the reuser to build two subclasses that overrides ATMControl(), LanguagePrompt(), and initialize(). The two subclasses will contain the reaction to an expired card and the prompts used by that new reaction that the reuser desires.

Slide 18:Conclusions

A hybrid of these four approaches can be used Understanding the different approaches to modeling and managing variability on a product line effects the lifecycle of the product line Modeling Variation points increases the amount of flexibility for the reuser by allowing them to create unique variants The degree of flexibility needed can impact the number of reusers The degree of flexibility can impact the changes to the core assets versus the reuser�s applications The degree of flexibility can impact the time to market for the applications A complex product line may require variation point if a core asset developer could not understand all variants Fewer resources put on core assets because not every variant must be part of the core assets Adds resources to the application development to build the unique variants VPM provides a mechanism to communicate the variation points to the reusers

Slide 19:Back Up

Slide 20:Introduction to VPM

VPM has the following qualities VPM builds on the idea of commonalities and variabilities from domain analysis VPM can be used with any software development process that contains variation points VPM visualizes the variation points VPM adds the variation point view to the requirements and reference architecture VPM uses the well-known and accepted UML VPM categorizes the variation points into three types, parameterization, inheritance, and callback VPM gives the reuser an understanding of how to build a variant from a variation point

Slide 21:Two Major Ideas

Developer of the core assets manages variability The core asset developer builds and maintains the variants used on the applications Reuser chooses between a set of variants for each variation point and creates an application When the reuser needs a variant that is not available, the core asset developer adds the variant to the core assets. Modeling the variation points, helps the core assets developer to manage and build new variants Variants A1 A2 B1 B1 Core Assets

Slide 22:Two Major Ideas

Reuser of core assets builds unique variants from the variation points Reuser has the flexibility of tailoring the core assets to his/her needs A variation point must be modeled such that the reuser has enough knowledge to build a variant The core assets developer no longer maintains every possible variant, only the variation points Variants that are unique to one application are maintained by the application developer Modeling the variation points, enables the reuser to build variants from variation points Variants A A1 A2 Core Assets

Slide 23:Requirements View

Shows the variation point in terms of the requirements of the core assets Created during the analysis phase The variation points are captured at the same time the requirements are captured

Slide 24:Requirements View

Enumerated Shall Statements A requirement in the Common Core Specification: The Common Core shall perform a function Variations: 1. vp ?m?o? ?VariationPointName?: The Common Core shall provide a mechanism where the reusers can specialize the function. Use Cases vp ?m?o? ?VariationPointName?: A mechanism will be provided which allows the reuser to specify an alternate action. Variation points are labeled with a �vp� for variation point followed by an �m� for mandatory or an �o� for optional.

Slide 25:Requirements View - Example

Enumerated Shall Statements A requirement in the ATM Core Specification: The ATM Core shall check for a stolen card and confiscate the card if stolen. Variations: 1. vpoStolenCard: The ATM Core shall provide a mechanism where the reusers can specialize the result of a stolen card. Use Cases vpoStolenCard : A mechanism will be provided which allows the reuser to add any action as a result of a stolen card. The default action is to confiscate the card.

Slide 26:Component Variation Point View

A composite view that shows all the variation points that belong to a particular component Shows if a variation point belongs to more than one component and if several variation points belong to one component Created during the architecture phase

Slide 27:Static Variation Point View

Shows the static parts of the variation point and their relationships Shows which classes and methods are involved in the variation point Created during the design phase

Slide 28:Static Variation Point View

Three types of static variation point view Inheritance; used when there is a need to specialize a particular function or method Parameterization; used when there is a need to specify the value of a parameter Callback; used when there is a need to add several functions to a component

Slide 29:Static Variation Point View - Inheritance

<<Variant>> [VariantName] ?methodName1()? {reuse only} <<Component >> ?CC Component Name? ?CC Class Name? ?attributeName? ?methodName1()? {variation point=vp?m?o? ?VariationPointName?} ?methodName2()? A UML tagged value is placed after the element it affects A UML constraint shows that it is for reuse only

Slide 30:Static Variation Point View - Callback

{reuse only} <<Component >> ? CC Component Name? ?CC Class Name? ?attributeName? ?methodName1()? ?registerCB(*VariantMethodPointer)? {variation point=vp?m?o? ?VariationPointName?} <<Variant>> [VariantClass] [variantMethod()]

Slide 31:Static Variation Point View - vpoStolenCard

�interface� IStolenCard reactToStolenCard (in cardID) {reuse only} 1 �subsystem� BankServer �database wrapper� DebitCard cardID: String PIN: String startDate: Date expirationDate: Date status: Integer limit: Real total: Real create (cardID) validate (in cardID, in PIN, out status) updatePIN (cardID, PIN) checkDailyLimit (cardID, amount) updateDailyTotal (cardID, amount) updateExpirationDate (cardID, expirationDate) updateCardStatus (cardID, status) updateDailyLimit (cardID, newLimit) clearTotal (cardID) read (in cardID, out PIN, out expirationDate, out status, out limit, out total) delete (cardID) registerStolenCardCB (in IStolenCard) {variation point = vpoStolenCard} 1 �variant� [StolenCardVariant] reactToStolenCard (in cardID) 1 �realizes� 1

Slide 32:Dynamic Variation Point View

Shows how to make the variant known to the rest of the components Created during the design phase

Slide 33:Dynamic Variation Point View - vpoStolenCard

�database wrapper� :DebitCard �initializer� [:TSInitializer] registerStolenCardCB(in StolenCardVariant()) The reuser�s initializer registers a callback with Debit Card. Debit Card then calls back the registered callback.

Slide 34:Proof of Concept

Two proofs of concept were conducted One took an already built product line with variation points and modeled the variation points using VPM The second took banking system case study [Gomaa 2000] and added six variation points to the ATM solution; they were then given to an independent developer for implementation The first one was implemented in C++ and the second was implemented in JAVA Demonstrated that variation points could be implemented using VPM

Slide 35:Summary and Conclusions

VPM is a method for modeling variation points Modeling the variation points communicates to the reuser how the core assets can be extended VPM views tell the reuser where the variation points exist and how to build a variant from a variation point

Slide 36:Modeling Variability Using Information Hiding - Example

ATMControl contains the reaction to an expired card. This allows the reuser to choose a reaction, e.g. Eject Card, and display a prompt saying the card is expired. One variation impacts two classes

Slide 37:Modeling Variability Using Inheritance - Example

ATMControl contains the reaction to an expired card. Subclasses are provided for each reaction and corresponding prompt. This allows the reuser to choose a reaction, e.g. Eject Card, and display a prompt saying the card is expired.

Slide 38:Requirements and Component Variation Point Views

The symbols ? ? are used to designate information supplied by the builder of variation point model. The symbols [ ] are used to designate information supplied by the reuser Each variation point starts with a vp, the third letter is either �m� or an �o� to indicate mandatory or optional. Enumerated Shall Statements A requirement in the Common Core Specification: The Common Core shall perform a function Variations: 1. vp ?m?o? ?VariationPointName?: The Common Core shall provide a mechanism where the reusers can specialize the function. Use Cases vp ?m?o? ?VariationPointName?: A mechanism will be provided which allows the reuser to specify an alternate action.