Minicourse - RiPLE : The RiSE Process for Product Line Engineering


Published on

Minicourse at III SBCARS (Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software), 2009, Natal, Brazil

Software Product Lines (SPL) is an important and effective way to obtain the benefits related to software reuse such as quality improvement, cost reduction, and improvements in time-to-market. However, in order to be effective and introduced in a company several issues should be considered such as tools, training, top management commitment, and, specially, a well defined process. In this tutorial, we will present the main ideas involving SPL and an initial process which involves activities related to scoping, requirements engineering, design, implementation, testing, and evolution.

Published in: Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Minicourse - RiPLE : The RiSE Process for Product Line Engineering

  1. 1. DO MOREDO MOREw w w . r i s e . c o m . b r
  2. 2. RiPLE: The RiSE Process forProduct Line EngineeringEduardo Almeida, Marcela Balbino, Danuza Neiva, Ednaldo Dilorenzo,Paulo Silveira, Ivan Machado, Thiago Burgos, Vanilson Burégio, Silvio Meira2Sep 10th 2009 SBCARS 2009 – Natal - Brazil
  3. 3. Agendag• Part I– Software Process– Introduction to RiPLE– Software Product Lines: An overviewSoftware Product Lines: An overview– RiPLE process• Riple-SCRi l RE• Riple-RE• Riple-DE• Part II– RiPLE process (cont.)• Riple-TE• Riple EM• Riple-EM– Case Study– Conclusion– Future Directions
  4. 4. Software ProcessSoftware Process4Sep 10th 2009 SBCARS 2009 – Natal - Brazil
  5. 5. Software Process• Software Development– complex systemstime to market– time-to-market– distributed development– ….• Expertsp• Turnover
  6. 6. Software Process – cont.• Importance– WhoWhat– What– When– How• Users• Organization
  7. 7. Software Process – cont.• A software process is a set of activities that leads to theproduction of a software product• Influences– Project | Methods | Tools– Project | Methods | Tools– Knowledge– Cost– Contract– …..[Sommerville, 2008]
  8. 8. Software Process – cont.• Process Model– Software Reuse• Why a new process?
  9. 9. The State-of-the-Art [Almeida, 2007][ , ]….
  10. 10. The State-of-the-Art – cont.• Systematic Reviews– Scoping• in evaluationin evaluation– Requirements• in evaluationDesign– Design• European Conference on Software Architecture (ECSA 2008)– Testing• in evaluation– Evolution• in evaluation– Tools• Journal of Information and Software technology 2009
  11. 11. RiPLE – The RiSE Process for Product LineEngineering
  12. 12. Integrated Effortg
  13. 13. RiPLE – RiSE Product Line Engineering Process• Stepsp– Core Assets Development– Product Development• ConceptsD i– Domain– Feature• Foundations– Process ModelProcess Model– Domain-driven– Iterative | Incremental
  14. 14. RiPLE – cont.• Elements– GuidelinesPrinciples– Principles– Language– Roles– Assets– Activities
  15. 15. Software Product Lines (SPL)Software Product Lines (SPL)15Sep 10th 2009 SBCARS 2009 – Natal - Brazil
  16. 16. A little bit of history…16
  17. 17. The basis of Product Line Engineering....g g• Henry Ford• “The father of assembly-line automation”• Model T production (1908)• Main concept: Interchangeble parts• based on the ideas of Honoré Blanc and Eli Whitney• Streamlined the production process
  18. 18. The Economy of scale!y• Line of motor cars• affordable, built quickly, high quality“A h“Any customer can havea car painted any colourth t h t lthat he wants so long asit is black” - Henry Ford
  19. 19. The Economies of scale!• Line of motor cars• affordable, built quickly, high quality“A h“Any customer can havea car painted any colourth t h t lthat he wants so long asit is black” - Henry FordC t i h i hCertain choices whereextremely limited!
  20. 20. Product Line Engineering (PLE)g g ( )• Economies of Scope• Mass customization:producing goods and services tomeet individual customersmeet individual customersneeds• Create an underlyingarchitecture for an Economies oflEconomies oforganizations productplatformscale scopemultiple identicalinstances of ai l d imultiple similarbut distinctd i d• Core assets can be reused toengineer new products from thesingle design areproducedcollectively, ratherthan individuallydesigns andprototypes areproducedcollectively, ratherengineer new products from thebasic familyy y,than individually
  21. 21. Software Product Lines (SPL)( )• Based on the ideas of PLEi bilit• Fundamental principle: variabilitymanagement• Allows to adapt a product to• Allows to adapt a product tothe customer needs• Adaptation is typically performedduring SPL development
  22. 22. The roots....• On the Design andDevelopment of ProgramFamiliesParnas, D.L.;, ;IEEE Transactions onS ft E i iSoftware Engineering,Vol. 02, Issue 01, March1976, pp. 1 - 9David Lorge ParnasDavid Lorge Parnas
  23. 23. Software Product Lines“A software product line is a set of software-intensive“A software product line is a set of software-intensivesystems sharing a common, managed set offeatures that satisfy the specific needs of asystems sharing a common, managed set offeatures that satisfy the specific needs of aparticular market segment or mission andthat are developed from a common set of coreparticular market segment or mission andthat are developed from a common set of coreassets in a prescribed way.Paul Clements and Linda Northrop 2002assets in a prescribed way.Paul Clements and Linda Northrop 2002Paul Clements and Linda Northrop, 2002Paul Clements and Linda Northrop, 2002
  24. 24. Essential Factors• Investment• Planning• Direction• Business StrategyM tManagement
  25. 25. Is Product Lines a new approach?• Small-Grained Reuse• Single-System Development with Reuseg y p• Component-Based Development• Reconfigurable ArchitectureR l d i f• Release and versions ofSingle Products
  26. 26. Organizational BenefitsOrganizational Benefits• To achieve large-scale productivity gains• To improve time-to-market• To maintain market presence• To improve product quality• To increase customer satisfaction• To achieve reuse goals• To enable mass customization
  27. 27. Product Line asset repository Benefits• Requirements• Architecture• Components• Modeling and Analysis• Testing• Planning
  28. 28. Essential ActivitiesCore AssetDevelopmentProductDevelopmentManagementDomain Engineering Application Engineering
  29. 29. Core Asset DevelopmentCore AssetDevelopmentManagement
  30. 30. Core assets• Core assets are the basis for production of products in• Core assets are the basis for production of products inthe product line• Core assets– Architecture {scope, styles, patterns, and frameworks}– Components– Test plans, Test cases– DocumentationDocumentation– Domain models– RequirementsC i l ff th h lf (COTS) t– Commercial off-the-shelf (COTS) components
  31. 31. Production PlanA d ti l d ib h th d t• A production plan describes how the products areproduced from the core assets– {reuser’s guide}{reuser s guide}• A Set of attached process {with the glue}A Set of attached process {with the glue}• Production Plan describes:– Tools– Metrics, Metric Plan
  32. 32. Product DevelopmentProductDevelopmentpManagement
  33. 33. Management• Critical role in the successful fielding of a productline• Technical– Core asset developmentCore asset development– Product development• Organizational– Trainingg– Funding– Risks
  34. 34. Some Successful CasesSome Successful Cases
  35. 35. P d Li H ll f FProduct Line Hall of Fame
  36. 36. Nokia: Mobile Phones• Case study– Mobile phones• Previous scenario– The initial software architecture for this product line addressedvariations in hardware, communication standards, and userinterfacesinterfaces
  37. 37. Nokia: Mobile Phones• Challenges– Language Challenge Abstract– The Hardware ChallengeThe Feature Challenge– The Feature Challenge• Strategies• Strategies– The current architecture is component based in the client-server style It allows separate service providers to be pluggedserver style. It allows separate service providers to be pluggedin or taken out without restarting the system
  38. 38. Nokia: Mobile Phones• Current Scenario– 32 different phones are manufactured covering sixdifferent protocol standards, a wide variety of functionalfeatures and capabilities, different user interface designs,and many platforms and environmentsand many platforms and environments• Results and Metrics– Nokia Mobile Phones is the worlds largest mobile phonemanufacturer, and they believe that software product linemanufacturer, and they believe that software product lineengineering has helped it to reach that position
  39. 39. PHILIPS: Product Line of SW for TV Sets• Case study– Televisions sets• Previous scenarioWhil i iti ll l l i ti f h d TV t i– While initially solely consisting of hardware, TVs now containfully equipped embedded computers to control the hardwareand to implement extra featuresand to implement extra features– These computers started small, with 1 kilobyte of code around1980, resulting in many million lines of code today, g y y
  40. 40. PHILIPS: Product Line of SW for TV Sets• Challenges– Complexity– Diversity, since televisions are produced in many differentvariants
  41. 41. PHILIPS: Product Line of SW for TV Sets• Strategies– The first step was the definition of a software componentd lmodel– The second step was the creation of a product line architecture– Changes had to be made to the existing developmentprocesses, which were optimized for the creation of singleproductsproducts– The fourth step was the adaptation of the developmentorganization to accommodate product line developmentorganization to accommodate product line development
  42. 42. PHILIPS: Product Line of SW for TV Sets• Current Scenario– Since 2002, all Philips mid-range and high-end televisionshave software derived from this product line– The product line supports three different hardware platformsp pp p• Results and Metrics– Today, there are 20 different software releases peryear where each release serving 1-5 differentyear, where each release serving 1 5 differentproduct types
  43. 43. Background – Importantg pConcepts49Sep 10th 2009 SBCARS 2009 – Natal - Brazil
  44. 44. Motivation• Variability– The ability or the tendency to change• Variability modelling– Goal: To support the development and the reuse of variable development assets– Iterative processIterative process• Abstraction levels–– CommonCommon and VariableVariable features of the domain {spl} are identifiedDomain requirements– Domain requirements– Domain architecture– Implementation– Test• Where–– DomainDomain engineeringengineering {definition}A li ti i i { l it d}– Application engineering {exploited}• Defining variability– The sumsum ofof allall activitiesactivities concerned with the identification and documentation ofThe sumsum ofof allall activitiesactivities concerned with the identification and documentation ofvariability
  45. 45. Definitions• Managed Variability– Defining and exploiting variability throughout the different life cycle stages of a spl– IssuesIssues• Supporting activities concerned with defining variability• Managing variable assets• Supporting activities concerned with resolving variability• Collecting storing and managing trace information necessary to fulfil these tasksCollecting, storing, and managing trace information necessary to fulfil these tasks• Examples–– A softwareA software componentcomponent cancan supportsupport differentdifferent implementationsimplementations– A search can be active oror passivep– A GUI component for threethree differentdifferent mobile phones• How to identify variability?–– WhatWhat doesdoes varyvary??WhatWhat doesdoes varyvary??• Variability subject – is a variable item of the real world or a variable property ofsuch na item–– WhyWhy does itdoes it varyvary??•• StakeholderStakeholder needsneeds technicaltechnical reasonsreasons marketmarket•• StakeholderStakeholder needsneeds,, technicaltechnical reasonsreasons,, marketmarket–– HowHow does itdoes it varyvary??• Variability object – is a particular instance of a variability subjectExamples• Examples– Variability subject - Search– Variability object – Active, Passive, Content...
  46. 46. Definitions (cont.)• Variation Point– It is a representation of a variability subject within domain assets enriched by contextual informationIt is a representation of a variability subject within domain assets enriched by contextual information• Variant– It is a representation of a variability object within domain assets• Variation Point and Variants– Used to define the variability of a domain [spl]• How to identify them?1. To identify the item of the real world that varies {variability subject}2 To define a variation point2. To define a variation point3. To define the variants• Examplesp– Customers, Analysts, Researchers.... – Search: “Passive”, “Active” {1}– Variation Point –Search Types– Variants – Passive, Active, Content, Facets, Keywords....Variants Passive, Active, Content, Facets, Keywords....
  47. 47. Definitions (cont.)• Variability in time– It is the existence of different versions of an asset that are valid at different timesSi l i i d i { l} i i– Single-system engineering or domain {spl} engineering– Evolution {configuration management}• Variability in space– It is the existence of an asset in different shapes at the same time– Browsing {requirements, use cases, test cases, components...}– New trend in research• External and Internal Variability– External – visible to customers– Internal – hidden from customersLEVEREFINCustomer needs…LSOFANEMENDesignRequirementsBST.TInternal Variabilty TestsComponents
  48. 48. Documentation of Variability• Required information– What varies?– What varies?• Documentation of the variation points– Why does it vary?Why does it vary?• Textual annotations of variation points and variants– How does it vary?How does it vary?• Documenting the available variants and linking them to domain elements– For whom is it documented?For whom is it documented?• Benefits– Decision making– Communication– Traceabilityy
  49. 49. Variability constraints• Variant constraint dependency– Variant requires variantq• Notification x Interest– Variant excludes variant• Variant to Variation Point constraint dependency– Variant requires variation pointVariant requires variation point• Asset publish x Access control– Variant excludes variation point• Variation Point constraint dependency– Variation Point requires Variation PointVariation Point requires Variation Point• Publish x Search– Variation Point excludes Variation Point
  50. 50. Features and Feature Model• Feature– An end-user-visible characteristic of a system– A distinguishable characteristic of a concept that is relevant to some stakeholder of– A distinguishable characteristic of a concept that is relevant to some stakeholder ofthe concept• Elements• Elements– Feature diagram– Feature definitions– Composition rules– Rationale for features
  51. 51. ExampleConferenceMandatoryFeaturesOptionalNotificationOptionalFeatureSubmission ReviewAccept/RejectAlternativeFeaturesNewsAssigmentResultAccept/RejectIndicationComplete PartialAutomatic M lAlternativeFeaturesAutomatic Manual
  52. 52. Feature Modeling: The importance• Reusable software– Variability• Key technique• Key technique– To Identify and capture variability• To avoid– Relevant features and variations points are not included in the reusablesoftwaresoftware– Many features and variations points are included but never used {complexity,costs}
  53. 53. Feature Models• Represents the common and the variable features of concepti t dinstances and ...• Dependencies between the variable featuresDependencies between the variable features• Elements– Feature Diagram– Semantic descriptions of each features– Client programs– Exemplar systems– Constraints– Priorities
  54. 54. Feature Diagrams (cont.)Mandatory FeaturesCf2f1f4f3Feature set {C f f f f }Feature set {C, f1, f2, f3, f4}
  55. 55. Feature Diagrams (cont.)Optional FeaturesCf2f1f3Feature set {C} {C f } {C f f } {C f } {C f f } {C f f f }Feature set {C} , {C, f1}, {C, f1, f3}, {C, f2}, {C, f1, f2}, {C, f1, f3, f2}
  56. 56. Feature Diagrams (cont.)Alternative FeaturesCf1 f2 f3 f4 f5Feature set {C f f } {C f f } {C f f } {C f f } {C f f } {CFeature set {C, f1, f3} , {C, f1, f4}, {C, f1, f5}, {C, f2, f3}, {C, f2, f4}, {C,f2, f5}
  57. 57. RiPLE – The RiSE Process for Product LineEngineering
  58. 58. RiPLE• RiPLE-SC: ScopingRiPLE RE R i t• RiPLE-RE: RequirementsRiPLE DE D i• RiPLE-DE: DesignRiPLE TE T t• RiPLE-TE: TestRiPLE EM E ol tion• RiPLE-EM: Evolution
  59. 59. RiPLE-SC: Scoping Process
  60. 60. Scoping on SPLp g• What is Scoping?What is Scoping?– It is the initial phase of a SPLp– It aims to identify products, features, potential of the domain andreusable assetsWh S i ?• Why Scoping?It determine the viability of the SPL– It determine the viability of the SPL– It maximizes the economical value of the SPL
  61. 61. Software Product Lines (SPL) and Agile Methods (AM)( ) g ( )A SPL aims to determine a set of products and features associated• A SPL aims to determine a set of products and features associatedand have as base a reusable platform• AM are a set of methods that have how base the values defined bythe Agile Manifesto, these are:– individuals and interactions over processes and tools;– working software over comprehensive documentation;– customer collaboration over contract negotiation; and– responding to change over following a plan• But in spite of clear differences both can have their particularBut, in spite of clear differences, both can have their particularbenefits joined in search of a same objective67
  62. 62. RiPLE - SC• Motivation– Lack of a complete scoping process which maximize thet ti l f th i AM d SPLpotential of the union among AM and SPLG lGoal– To define an agile scoping process by providing phases, tasks,i t t t l d id li f t ti finputs, outputs, roles and guidelines for construction of aplanning iterative and incremental which use as base agileaspects, making possible determine of form agile a scope whichmaximize the economical return with the SPL
  63. 63. RiPLE - SC :: Overview• It is performed in an iterative and incremental way usingagile values, principles and techniques• It is defined in a systematic way
  64. 64. RiPLE - SC :: Overview• The RiPLE-SC consists of four main phasesp– Pre-Scoping– Domain ScopingP d t S i– Product Scoping– Assets Scoping• The roles are relevant in these phases– Scoping expertp g p– Customer– Domain expertMarketer– Marketer– Developer– Architect– SPL manager
  65. 65. RiPLE - SC :: Pre-Scopingp g• Pre-Scoping meeting– It defines stakeholders and respective rolesIt identifies business goals– It identifies business goals– It identifies the organizational and operational contexts• Analyze Market– It is optional– Analyze market is not a trivial task– The marketers’ knowledge about the tendencies of the domainmarket segments in which the product lines are inserted is essentialmarket segments in which the product lines are inserted is essentialin this phase
  66. 66. RiPLE - SC :: Domain Scopingp g• It is defined in a workshop of domain analysisf• It aims to identify the domains and sub-domains morerelevant for SPL• The workshop presents four well-defined stepsReview domains– Review domains– Identify sub-domains– Analyze sub-domains andy– Prioritize domains and sub-domains
  67. 67. RiPLE - SC :: Product Scopingp g• The goal is to identify the products more relevant for SPLand their features• Five tasksIdentify products– Identify products– Construct user stories– Identify featuresy– Features review meeting and– Construct product map
  68. 68. RiPLE - SC :: Product Scoping – Product Mapp g p
  69. 69. RiPLE - SC :: Assets Scopingp g• The goal of the assets scoping is to determine anappropriate set of assets for product line• Three tasks:• Three tasks:– Create metrics of characterization and benefit– Apply metricsApply metrics– Prioritize product map
  70. 70. RiPLE - SC :: Assets Scopingp gE l f h t i ti d b fit t i i i• Example of characterization and benefit metrics in a genericdomain:
  71. 71. RiPLE-RE: Requirements Engineering
  72. 72. Introduction• Software Product Lines– Activities• Requirements Engineering– More products andstakeholders– Attention to variabilities andcommonalities– Lack of a systematic process(Clements and Northrop, 2001)78
  73. 73. RiPLE-RE :: Overview79
  74. 74. RiPLE-RE :: Activity Model ScopeyTasks80
  75. 75. RiPLE-RE :: Task Elicit• Identifying commonalities and variabilitiesId tif i f t d• Identifying future needs• Information source x Context81
  76. 76. RiPLE-RE :: Task Model FeatureTypes Constraints82
  77. 77. RiPLE-RE :: Task VerifyyIncompleteness, inconsistency, ambiguity, traceabilityd t d di ti i th DRSand standardization in the DRSInstantiated DRS is useful to verify the consistency,completeness and ambiguitiesVerification Report• - Problem type, cause and severity83
  78. 78. RiPLE-RE :: Activity Define RequirementsyTasks84
  79. 79. RiPLE-RE :: Task Describe Requirements [1]Variability Scope– Whole requirement (Mandatory and variant)– Requirement text fragment (Variation Point)Requirement Attributes– IdPoint Variation Attributes– Id– Type– Name– Variability Type– Description– Variants– CardinalityVariability Type– Binding Time– PriorityR ti lCardinality– Binding Time– ImplicationE l i– Rationale– Description– Implication– Exclusion85– Exclusion
  80. 80. RiPLE-RE :: Task Describe Requirements [3]• Template in XML86
  81. 81. RiPLE-RE :: Task Describe Requirements87
  82. 82. 88
  83. 83. RiPLE-RE :: Activity Define Use CasesyTasks89
  84. 84. RiPLE-RE :: Task Describe Use Cases [1]• Variability Scope– Whole use case (Mandatory and variant)– Use case part (Variation Point)Use Case Attributes Point Variation Attributes– Id– Name– Variability Type– Main Flow– Alternative FlowE ception Flo– Id– DescriptionCardinalityy yp– Binding Time– RationaleActors– Exception Flow– Post Conditions– Implication– Cardinality– Variants– Binding Time– Actors– Dependency– Preconditions– Exclusion – Implication– Exclusion90
  85. 85. RiPLE-RE :: Task Describe Use CaseointationsriationPmallvariaVarinsm91
  86. 86. RiPLE-RE :: TraceabilityyExternal AssociationCompositionImplicationExclusionInternal Association92
  87. 87. RiPLE-DE - Design
  88. 88. RiPLE-DE Overview
  89. 89. RiPLE-DE Overview• The main purpose is to be pluggableReq irements implementation e ol tion– Requirements, implementation, evolution• InputsInputs– Features model (Mandatory)– Stakeholders list (Mandatory)– Non-functional requirements (Mandatory)– Quality scenarios (Optional)D i i t (O ti l)– Domain requirements (Optional)– Domain use cases (Optional)• Outputs– Domain Specific Software Architecture (DSSA)p ( )– Quality Scenarios Document
  90. 90. Architectural Drivers Identification• Develop quality scenarios (If not provided)• Identify main features• Identify main quality attributes
  91. 91. Architecture Details Definition• Define which architectural views will be documented and inwhich level of details based on stakeholders listSt t l i (M d t )– Structural view (Mandatory)– Behavioral view (Mandatory)– Process view (Optional)Process view (Optional)
  92. 92. Architecture Details Definition
  93. 93. Architecture Details Definition• View Levels– Structural View• Low: modules definition• Medium: modules and component definitions• High: modules, components, and classes– Behavioral View• Low: main sequence diagramsq g• High: sequence diagrams for all use casesProcess Vie– Process View• Low: main processes activities of the domain• High: all processes activities of the domain• High: all processes activities of the domain
  94. 94. Represent Architecture• Structural View– Consists of defining modules, components, and classes with itsi bilitvariability
  95. 95. Structural View• Components are definedbased on the featured lmodel• Groups of features aredefined to form acomponent• The group top levelfeature defines thet i bilitcomponent variability
  96. 96. Structural View• Classes are definedaccording to the featuresl ti hi i threlationship using theguideline proposed by[Almeida2007][Almeida2007]
  97. 97. Behavioral ViewD fi di b d l d fi d i• Define sequence diagrams based on classes defined instructural view and the messages variability• Variant messages are represented with the variant id• Variant messages are represented with the variant idstereotype.
  98. 98. Process View• Define the main process for the domain• Define process variabilities• Define process variabilities• It is not mandatory if the domain does not have complexprocesses
  99. 99. Identify Design Decisionsy g• Consists of identifying and recording the main architecturaldecisions for the domain– Ex.: Programming language– Application server• Useful for avoiding architecture deprecation• It can be defined during all the process life cycle• It can be defined during all the process life cycle
  100. 100. RiPLE-TE - Testing106
  101. 101. Introduction• Software Product Line Testing– Testing as a Software Quality instrument• Assist developers to identify faults• Assist developers to identify faults• Determine whether a product can perform as specified by itsrequirements– Peculiar Aspects to Product Lines• Examines Core Assets• Examines Product Specific Software• Examines Product-Specific Software• Interactions among them– Responsibilities distribution across the organizationp g– Planning looking at extracting strategic reuse benefitsSource: [Clements, 2001], [McGregor, 2001]107
  102. 102. Testing Strategiesg g• Testing Product by Product– Critical Systems• Incremental Testing of Product FamiliesR i T ti– Regression Testing• Reusable Asset Instantiation– Test Assets created in CAD• Division of Responsibilities• Division of Responsibilities– CAD and PD108Source: [Tevanlinna, 2004]
  103. 103. The RiPLE Testing Processg• Testing considered along the Software Dev. Lifecycle– Testing Phases X Development PhasesTraceability is truly necessary– Traceability is truly necessary– Variability concerns must be handled• Interaction with other RIPLE disciplines– Scoping – RIPLE-SCScoping RIPLE SC– Requirements – RIPLE-RE– Analysis & Design – RIPLE-DE– Implementation - RIDE– Evolution – RIPLE-EM109
  104. 104. The RiPLE Testing ProcessgCore Asset DevelopmentRiPLE-RERiPLE-DERiDERiPLE-TERiPLE-SCRiPLE-EMReq. Design Impl.RiPLE-TEProduct Development110
  105. 105. The RiPLE Testing Processg• Testing Roles– Test ManagerTest Architect– Test Architect– Test Analyst– TesterOne can assume morethan a role as well as a• Other Stakeholders– Developerthan a role as well as arole can be assumed bymore than one individual.– Customer– Software ArchitectP j t M– Project Manager– Requirements Analyst– Configuration Manager111Configuration Manager
  106. 106. The RiPLE Testing Processg• Testing Artifacts– Test PlansTest Cases– Test Cases– Test Reports– Test Logsg– Test Scripts– Test Suites112Source: [IEEE, 1998], [McGregor, 2001], [Clements, 2001], [Pressman, 2005],
  107. 107. The RiPLE Testing ProcessgTest Planning Static AnalysisUnit Testing IntegrationT ti (CAD)CADCADTesting (CAD)System TestingAcceptanceIntegrationSystem TestingTestingTesting (PD)PDPD113
  108. 108. The RiPLE Testing ProcessgCADCADTest Planning• Scope, Approach, Resources, Schedule• Items and Features to be tested• Testing Tasks to be performed• Roles and Attributions• Risk Analysis114
  109. 109. The RiPLE Testing ProcessgCADCADStatic Analysis• Validate:– Feature Model– Use Cases and Requirements– DesignF t D d– Feature Dependency• Checklists and Validation Meeting• We are not covering “Inspection”115
  110. 110. The RiPLE Testing ProcessgIntegrationCADCADUnit Testing IntegrationTesting (CAD)• Activities– Plan Tests– Create Test Assets– Execute TestsR t T t– Report Tests• Regression Testing when necessary• A Component is considered a Unit in this approach• A Component is considered a Unit in this approach116
  111. 111. RiPLE-TE : Unit Testingg• Objective:– Exercises a unit (component) of code– Classes and methods integration• Source informationComponent Code– Component Code– Component Specification117
  112. 112. RiPLE-TE : Unit Testingg118
  113. 113. RiPLE-TE : Unit Testingg119
  114. 114. RiPLE-TE : Integration Testing (CAD)g g ( )• Objective:– Reference Architecture Conformance (Code x Specification)Module Testing– Module Testing– Components integration testing• Source information– Architecture Specification (e.g.: Behavioral and Structural views)p ( g )– Feature Model– Feature Dependency– Code120
  115. 115. RiPLE-TE : Integration Testing (CAD)g g ( )• Integration Testing Strategies– Non-Incremental (Big-Bang)– Incremental• Bottom-up• Top-Down Depth-First• Depth-First• Breadth-FirstBreadth-First121
  116. 116. Feature ModelRise Chair122
  117. 117. Test Asset Creation123
  118. 118. RiPLE-TE : Integration Testing (CAD)g g ( )• Combinatorial Explosion124
  119. 119. The RiPLE Testing ProcessgPDPDSystem TestingAcceptanceTestingIntegrationTesting (PD)• Activities– Plan Tests– Create Test Assets– Execute TestsR t T t– Report Tests• Regression Testing whenever necessary125
  120. 120. RiPLE-TE : Integration Test (PD)g ( )• Objective:– Product Specific Components Integration TestingProduct Architecture Testing– Product Architecture Testing• Source information• Source information– Product Map– Feature Model– Feature Dependency– Architecture Specification126
  121. 121. Architecture Regression Testingg g• Objective– Test the reference architecture after modification or evolutionConformance between product and reference architectures– Conformance between product and reference architectures– Test product specific architecture127
  122. 122. Types Of Regressionyp gCorrective Regression Progressive Regression• Specification is not changed • Specification is changed• Involves minor modification tocode• Involves major modificationMan test cases can be re sed Fe er test cases can be re sed• Many test cases can be reused • Fewer test cases can be reused• Invoked at irregular intervals • Invoked at regular intervals128
  123. 123. Regression Testing Approach steps 1/3g g pp p1. Graph Generation– Control Flow GraphControl Dependency Graph– Control Dependency Graph– Program Dependency Graph– JIG (Java Interclass Graph)( p )2. Graph Comparison– Compare the graphs for each version of the software (Originaland Modified)Identify critical paths– Identify critical paths129
  124. 124. Regression Testing Approach steps 2/3g g pp p3. Changed Paths Analysis– Analysis the critical pathsClassify existing Test Case– Classify existing Test Case• Obsolete• Reusable• Retestable4. Instrumentation– To be sure about the test cases efficiency and coverage130
  125. 125. Regression Testing Approach steps 3/3g g pp p5. Test Design– Design new test cases (Specification Changes)Update test cases– Update test cases6. Test Suite Composition6. Test Suite Composition– Group Related Test Cases7. Test Case Priorization– Critical Variabilities First– Features for a specific product– Specific architecture quality attribute131
  126. 126. RiPLE-EM - Evolution132
  127. 127. RiPLE-EM :: Overview2 Fl• 2 Flows– Core Assets FlowProduct Flow– Product Flow• 3 Disciplines3 Disciplines– Change Management– Build Management– Release Management
  128. 128. RiPLE-EM :: Overview
  129. 129. RiPLE-EM :: CADxPD CommunicationTh P i R (PR) i h• The Propagation Request (PR) is a way to propagate theevolution (changes made to an asset or product) of a certainasset or product to another asset or product.p p• It is managed by the change control tool used.
  130. 130. RiPLE-EM CAD :: Macro Flow
  131. 131. RiPLE-EM CAD ::Release PlanningRelease Planning• This activitiy is performed inparallel with the development,and it can be refined until theand it can be refined until therelease execution moment
  132. 132. RiPLE-EM CAD :: Macro Flow
  133. 133. RiPLE-EM CAD :: Change Managementg g
  134. 134. RiPLE-EM CAD :: Macro Flow
  135. 135. RiPLE-EM CAD ::Build ManagementBuild Management
  136. 136. RiPLE-EM CAD :: Macro Flow
  137. 137. RiPLE-EM CAD :: Release Execution
  138. 138. RiPLE-EM PD :: Macro Flow
  139. 139. RiPLE-EM PD ::Release PlanningRelease Planning• This activitiy is performedin parallel with thedevelopment and it candevelopment, and it canbe refined until therelease execution moment
  140. 140. RiPLE-EM PD :: Macro Flow
  141. 141. RiPLE-EM PD ::Change ManagementChange Management
  142. 142. RiPLE-EM PD :: Macro Flow
  143. 143. RiPLE-EM PD :: Build Managementg
  144. 144. RiPLE-EM PD :: Macro Flow
  145. 145. RiPLE-EM PD :: Release Execution
  146. 146. Case Study: Papers Managementy p gSoftware Product Line152
  147. 147. Motivation• Lack of accessible and integrated SPL processes– Isolated projects focused on specific issuesScope req irements design etc• Scope, requirements, design, etc...– Lack of details about the processes and their practical results• Integration and validation of the RiPLE process– Different disciplines have been developed by different studentsDifferent disciplines have been developed by different students– Necessity for validating each discipline and its interaction withothers in a more practical way153
  148. 148. Main Goal• Creation of a comprehensive reference project– Dissemination of the reuse culture• Fully documented SPL (results available online)– Case study with international visibility– Acquisition and transference of knowledge among theparticipants– Improvement of the reuse/SPL techniques and tools154
  149. 149. First step: Domain SelectionFirst step: Domain Selection...155
  150. 150. Domain• Document submission systems– Submission– Review– Notification– Logginggg g– Report– ....
  151. 151. Domain• Initial domain: paper submission– Easier to understand– Experts accessible• Some rise members developedapplications in such domain– Variabilities enough to create a SPL– Conferences, journals,workshops, etc...p ,
  152. 152. Involved peoplep p• Team– 13 people (reuse specialists)• 4 Ph.D students• 9 M.Sc. students9 M.Sc. students• 1 customer and 3 domain experts– Professors• Roles– Internal– Internal• SPL manager; SPL Engineers (SPL Architect, Developer,Testers);Requitements Analyst; Domain Analyst; Scoping Expert; SQA; CCBExternal– External• Domain Expert; Customer; End Users
  153. 153. SchedulePhase PeriodPhase I – Implementation of core assets and an initial product May-09 - Oct-09Phase II – Addition of new features and implementation of other products Oct-09 – Mar-10Phase III – Inclusion of a new product in the product line Mar-10 – Aug-10Ph I ti iti• Phase I – macro activities– Scope definition– Domain analysisDomain modeling– Domain modeling– Domain architecture– Identification of core assets– Core assets: implementation and componentization– Core assets: implementation and componentization– Initial product derivation– Process adaptation
  154. 154. Overview of the process and artifactsCore Asset Development ManagementNon code assets Components (code)Featuremodel ReferenceArchitectureSPL PlanRiPLEProcess (EPF)Non‐code assetsUse CasesFeaturesQ liProductMap CM PlanProcess (EPF)ScopedocsFeaturesInteractionPrototypeQualityscenariosProjectwebsiteTraceabilitymatrixTest docsProduct DevelopmentProduct 1 Product 2 Product NProduct PlanProduct 1Set of features 1Product 2Risk PlanT i iSet of features 2Set of features N...May 23, 2013Trainings
  155. 155. Products: RiSE Chair Family• R-CHAIR• R-CHAIR– Conference management– Submission/revision procedures• R-CHAIR Plus– Journal management– Different submission/revision life cycle– Different submission/revision life cycle• Smart R-CHAIR– General event management– Papers reviewers are defined automatically (conflicts)
  156. 156. Scoping162
  157. 157. Scopingp g• Main activities executed– Analysis of existing systemsIdentification of features– Identification of features– Identification of products– Creation of the product mapp p• Artifacts– Feature list, product map, products description
  158. 158. Scoping: problems and solutions• Understanding the domain...– Analysis of existing systems– Analysis of existing systems• 11 systems analyzed• Different groups• Initial identification of features• Initial identification of featuresTool URLC C // / /CyberChair SBC IET Software http://mc manuscriptcentral com/iet senJournal IET Software Technology Journal FACEPE CNPq http://efomento cnpq br/efomento/E-Fomento CNPq Submission Microsoft
  159. 159. Scoping: problems and solutionsp g pInitial list of features• Consolidation of the featuresInitial list of features(consolidated)– Problems with FeaturesDefinition– Granularity level– Lack of a “deep” knowledge ofp gthe domain– the most experiencedprofessionals were included in thepgroup of domain experts
  160. 160. Scoping: problems and solutionsp g p• Identification of products andti f th d t Product mapcreation of the product map– Lack of metrics to supportppthe decisions– What features should beincluded in the products?included in the products?
  161. 161. Scoping - Contributionsp g• Main improvements to the RiPLE-SC– Pre-scoping phase– Identification of business goals– Domain scoping– Workshop of domain analysis– Prioritize domains and sub-domains– Product scoping– Features review meeting– Assets scoping– Create metrics of characterization and benefit– Prioritize product map
  162. 162. R i tRequirements168
  163. 163. Requirementsq• Main activities– Construction of the Feature Model– Identification, specification and validation ofrequirements and Use Cases– Contruction of the traceability matrixSplit– Split
  164. 164. Requirementsq• Artifacts– Feature model, requirements , use cases,, q , ,traceability matrix
  165. 165. Requirementsq• Problems and SolutionsProblems and Solutions– Redundancy of information (req x ucs x FM)Construction of tools to manage such redundancies and– Construction of tools to manage such redundancies andthe xml specifications– Adaptation of the “Split tool”– Feature validation process– internal member responsible for validating the featuresbefore sending them to “external evaluation”
  166. 166. Requirementsq• Problems and Solutions– Granularity level of the features (recurrent problem!)– Re-analysis of the feature model– Distinct feature models (abstraction level)– Using a model for each (major) stakeholder viewUsing a model for each (major) stakeholder view– Different tools were used
  167. 167. Requirementsq• Problems and SolutionsDifficult to identify variabilities in– Difficult to identify variabilities inscreens– Solution: PrototypesScreen_UC03_VP1.V1-FromPrevious Screen_UC03_VP1.V2-FromScratch
  168. 168. D iDesign174
  169. 169. Designg• Main activities– Identification and priorization of quality attributesDefinition of architectural views– Definition of architectural views– Specification of modules, components and classes
  170. 170. Designg• Artifacts– Domain specific software architecture document; diagramsDomain specific software architecture document; diagrams(components, classes, modules)• core-business: submission, event management, revisionShared services: logging notification reporting accesscontrol• Shared services: logging, notification, reporting, accesscontrol– Specification of variabilities
  171. 171. Designg• Quality scenarios documentationScenarios > quality attibutes– Scenarios -> quality attibutes– Specification of variabilities in the scenarios
  172. 172. Designg• Problems and solutions– Lack of a deploy viewNon fuctional variants should be considered– Non-fuctional variants should be considered• It is important to stablish a limit• Otherwise the creation of an architecture could be inviable– Specification of features interactions• Modification dependencyp y• Concurrent dependency• Sequential dependencyDecomposition and Generalization Dependency• Decomposition and Generalization Dependency• Usage dependency• Exclude dependency
  173. 173. I l t tiImplementation179
  174. 174. Implementation• The architecture was divided in twopThe architecture was divided in twolayersThe front end (gui): related to– The front-end (gui): related tothe productsResponsible for the product– Responsible for the productcustomization and “glue”– The back-end: related to theProductThe back-end: related to thecore assets– Common services– Common services– Business rulesCore Assets180Core Assets
  175. 175. Implementation: Technologiesp g• In the beginning of the implementation phase some technologieswere discussed by the team• Front-end: FlexFront end: Flex– Rich interface– Flexibility to create new components• Variability can be developed– Easy integration with other technologies as Java• Back-end: Java– Maturity and team knowledgeJava frameworks used:– Java frameworks used:• JPA using Hibernate  for the persistence• Spring  for the inversion of control of the application, transaction andsecurity management181y g
  176. 176. Implementation: Trainingsp g• Flex: a new technology for some members– Some trainings were necessary• Some trainingsFlex concepts– Flex concepts– Flex and Java integration– Using of Cairngorm as the Flex MVC architectureg g182
  177. 177. Implementation: core assetsp• Core assets developed (8/13):p ( )– Event Management– AccessControlService– DataAccessServiceDataAccessService– FileUploader– SubmissionManagementServicePdfGenerator– PdfGenerator– ReportService– Notifier• The core assets were developed with Java– These components will be used by the productsp y p– Each product should have the user interface developed in Flex,as showed previously183
  178. 178. Implementation: Variabilitiesp• Decorator Design PatternDecorator Design Pattern– Optional variability type– Features:• Event (mandatory)• CreateEventFromScratch (variant – mandatory)• CreateEventFromPrevious (variant – optional)• CreateEventFromPrevious (variant – optional)• Dependency Injectiony j– OR variability type– Features:R t ( d t )• Report (mandatory)• PdfExtension type (variant - optional)• HtmlExtension (variant - optional)( p )
  179. 179. Some data: time distributionSProcessadaptations7%Other activitiesScope23%Trainings6%7% 9%Requirements23%Design17%Implementation15%Time distribuition17%120140160180200ScopeRequirementsDesign406080100120HoursDesignImplementationTrainingsProcess adaptationsOther activities020Activities
  180. 180. Some data• Scope– 3 products– 41 features identified• Requirementsq– 49 functional– 18 non-functional28 use cases specified– 28 use cases specified– 23 screens (prototype)• Design– 15 quality scenarios– 13 components– 7 modules7 modules• Implementation– 8 core assets implemented20 l– 20 classes
  181. 181. General Issues and Lessons Learned• Feature definition and granularity levelTh t h ld h th i i !– The team should share the same vision!• Domain expert Vs Experienced users– Two different concepts!• Initial SPL tasks can be time wasting• Difficult to follow the process– Lack of standardization among the RiPLE disciplines– Adaptations were peformed during the project• Big team and people idleg– Too many people to work in the same activity• Team motivation: conflict of interests• Difficulty of dealing with distribution
  182. 182. Next StepspPhase I Phase II Phase IIIMay-09 Out-09 Mar-10 Aug-10We are here!• Derivation of products• Derivation of products• Validation of the RiPLE EM• Validation of the RiPLE-EM• Products evolution and derivation• Validation of the RiPLE-TE• Assets and products
  183. 183. RiPLE Future DirectionsRiPLE – Future Directions189
  184. 184. New Directions• Research– Risk Management– Measurement– Feature InteractionFeature Interaction– Architecture Recovery– Quality AttributesQ lit– Quality• Inspection• Test case selection | priorization– Product Derivation– Introduction in Companies– Tools• Agile
  185. 185. ConclusionsConclusions191
  186. 186. Conclusions• RiPLE– Scoping– Requirements– DesignDesign– Test– Evolution• Case Study– On going projectYou can participate!– You can participate!• Industrial caseNew directions• New directions
  187. 187. More information• RiSE –• RiSE Labs –• INES –• World of Reuse –• CRUiSE -• Events• Events– WiRE –– RiSS -
  188. 188. RiPLE: The RiSE Process forProduct Line EngineeringEduardo Almeida, Marcela Balbino, Danuza Neiva, Ednaldo Dilorenzo,Paulo Silveira, Ivan Machado, Thiago Burgos, Vanilson Burégio, Silvio Meira194Sep 10th 2009 SBCARS 2009 – Natal - Brazil