Hope you don’t get sleep during the talk - RCOST - HomePage · Life-cycle of assets ... Nokia...

1

Hope you don’t get sleepduring the talk

2

Product Line Engineering for Web Systems

Dr. Rafael CapillaUniversidad Rey Juan Carlos

http://www.urjc.es

Madrid, SPAIN

Contact me at:([email protected])

3Product Line Engineering for Web Systems

R. Capilla, Benevento, Italy, March 2006

Content

1. Approaches to Product Line Architectures(PLA)

2. Variability Modeling & Management

3. PLA for Web Systems

4. Conclusions

4

PLA Approaches3 main axes in Product Families

Main assetsArchitecture, Components, Systems

ViewsViews ofof thethe organizationorganizationBusiness, Organization, Process, Technology

LifeLife--cyclecycle ofof assetsassetsDevelopment, Deployment, Evolution


R. Capilla, Benevento, Italy, March 2006

5

PL start-up alternatives (motivation)

Evolution of a set of products to a PFReplacement of products by a PFEvolution to a new PFDevelopment of a new PF


R. Capilla, Benevento, Italy, March2006

PLA Approaches

6

PL heavy approaches. STARS

Domain AnalysisMarket Analysis

ArchitectureConstruction

InfrastructureDevelopment

DOMAIN ENGINEERING

Product LineIdentification

COMPONENT MANAGEMENT

ArchitectureCustomization

ProductComposition

BusinessAnalysis

APPLICATION ENGINEERING

ProductRequirementAnalysis



PLA Approaches

7

PL heavy approaches

DomainEngineer Family

Definition

FamilyProduction

Facility

FamilyMembersFamily

MembersFamilyMembers

ApplicationEngineer

DOMAINENGINEERING

APPLICATIONENGINEERING

Creates

Uses

Creates and Uses

Family-Oriented Abstraction, Specificationand Translation (FAST)David M. Weiss & Chi Tau Robert Lai, 1999



PLA Approaches

8

PL heavy approaches. FAST

Qualify Domain

Engineer Domain ApplicationEngineeringEnvironment

Engineer Application

Model Application

Produce Application

Deliver and Support Application

Applications

Analyze Domain

Implement Domain



PLA Approaches

9

PL heavy approaches. PuLSE Overview (Fraunhofer institute)



PLA Approaches

10

PL heavy approaches. SEI PL Practice initiative



PLA Approaches

ManagementActivities of technical and organizational management, without which the PL initiative will collapse

11

Domain Engineering

DomainAnalysis Domain

Design DomainImplementation

ApplicationRequirements System

Design Coding

Application engineering

RequirementsTraceTrace

Components

Code

DomainExperience

Domain terminologReference requirements Reference Architecture

ReusableAssets

Feedback/adaptation/reverse architecture

NewRequirements

Depósito deActivos

The PRAISE Method



PLA Approaches

12

PL heavy approaches. ITEA EUREKA Projects

ESAPS-CAFÉ-FAMILIES

http://www.esi.es/en/Projects/esaps/esaps.htmlhttp://www.extra.research.philips.com/euprojects/cafe/http://www.esi.es/en/Projects/Cafe/publicResults.htmlhttp://www.esi.es/en/Projects/Families/http://www.itea-office.org/



PLA Approaches

13

CAFÉ Process Reference Model



PLA Approaches

14

PL Heavy vs Lightweight approaches. GEARS (Krueger)

http://www.biglever.com

GEARS

FeatureDeclaration

ProductDefinitions

VariationPoints

Modeling the scope of the variation in the PL

Modeling of product instances that can be createdfrom the values of the features

Encapsulation of the variants at code and designlevels



PLA Approaches

15

PL Lightweight approach. GEARS (Krueger)



PLA Approaches

16

PL Lightweight approach. GEARS (Krueger)



PLA Approaches

17

PL Heavy approach. GEARS (Krueger)



PLA Approaches

18

Variability Modeling & ManagementNokia Product Line

8855 6510 8910 5210 8270 8390

8265 3350 7650 6310 6360



19

Philips Medical Systems

ProductPopulation

ArchitecturesMedical Imaging Platform Medical Imaging Platform

Architecture & Software ComponentsArchitecture & Software Components

ProductFamily

ArchitecturesXX--Ray Acquisition PlatformRay Acquisition Platform

EasyVisionEasyVisionWorkstation PlatformWorkstation Platform

Architectures

URFURF SurgerySurgery CVCV RADRADMRMR CTCT EVMEVM RISRIS PACSPACSATLATL



Variability Modeling & Management

20

Automotive Systems

Vehicle Navigation Systems(# variants >> 10)

Driver Assistance Systems(# variants >> 100)

Engine Control Systems(# variants >> 1000)




21

Other Experiences

Celsius Tech (Naval Electronic Systems)30 groups of functions with 20 functions/groupRange of 3000 to 5000 parameters / componentMore than 100 sistems y 25 different conf.

Market Maker (Financial Systems)Cummins (Diesel Engines)

9 engine typesFrom 4 to 18 cylinders5 processors10 fuel engine types12 electronic control types




22

Concept of Variability

Common aspects• Common characteristics part of a Product Family• A template for building software systems• Standard parts belonging to the same system family

Variability

• Differences between software systems• Customizable parts of systems• Diferentes types of variations




23

Definitions

Variation Point: An area affected by variability

Variant: A customizable option of a variantion point

Variability mechanism: Method or technique by whichwe represent the vatiability

Varaiability analysis: The process by which the variable partsare identified

Binding Time: The moment in which the variability is realized




24

Vehicle PL Feature Model

Car Product Line

Car Model A Car Model B

Common Features Common FeaturesFeatures Model A Features Model B

Versions for Car A and B




25

FODA (Featured-Oriented Domain Analysis) Kyo C. Kang, 1990

Transmission Horsepower

Manual Automatic

AlternativeFeatures

RationaleManual more fuel efficient

Composition RuleAir conditioning requiresHorsepower > 100

CarOptionalFeature

MandatoryFeatures




26

Extensions to FODA. Quantitative values (Capilla, Dueñas PFE-2001)

ODP::VoIP-FR

Processor Memory Storage Comm Video VoIp Audio

G.729 G.711 G.723.1

Qos

CodecsDelay SerDelay CIR Tc Be BECN cRTP VAD

(Max=150 ms) (Max=20ms) (Max=125ms (<disable Router’s CPU> if QoS=10ms) <CPUUsage> GT 75%)

Qos

Codecs

QosQos

Qos




Values: Max / Min, Range, NTimes

Action = <specific action> if <feature>

{GT | LT | EQ | GE | LE OutRng | InRng | Ntimes} value):

27

Extentions to FODA. Feature dependencies (Lee & Kang, 2004)

Operational dependency: Implicit or explicit created relationshipsbetween features during the operation of the system => Impact in thedevelopment of the assets of the PL

• Usage dependency: A feature may depend on other featuresfor its correct functioning or implementation.

• Modification dependency: The behavior of a feature may be modified by other feature, while it is in activation.

• Exclusive-Activation dependency: Some features must not be active at the same time.

• Subordinate-Activation dependency: There may be a featurethat can be active only while other feature is active.

• Concurrent-Activation dependency• Sequential-Activation dependency




28

UML ModelingOCL constraints

package 1<<subsystem>>

Class fooAtt1 : Integer = 2<<vp2>> Att2 : StringStereotypes

Tagged Values

Propietary (Several authors)• FODA, FORM• Feature-RSEB• Bosch• Generative Programming

Meta-models




29

Binding Time (C Fritsch et al.2002)

Binding Time

Integration

Assembly

Run Time

Compilation

Source Selection

Image Build

First o Every Startup

Dynamic

Configured at the End Of Line

ProgrammingCore Asset Development

Product Development




30

Requirements Func. Req XX:The bit rate for Video Codec Ymust be greater than 10

Variation PointUML class

ImplementationLevel

Design

Compilation /Run Time

#Ifdef BTVIDEOCODE GT 10#endif

Bit Rate<<variant>> BTVideoCodec : Integer = 10

<<variation point 1>>

LifeCycle Products Decision Model

Bit Rate Video Codec Y> 10

Variability implementation lifecycle




31

Variability implementation phases

Identification

Constraining

Implementation

Management

WHEN and WHERE variability is needed

Definition of constraints for each VP(e.g.: variants, dependencies, binding time)

Representation

Implementation technique

WHICH Modeling technique




32

MPEG-4-Level-0 {Variant}(from Proxy)

H.263 {Variant}(from Proxy)

GSM 1 {Variant}(from Proxy)

AMR {Variant}(from Proxy)




VideoCodec

header : Stringlevel : Integerpicture_size : Integerimage_quality : Integermax_bit_rate : Integerencoder_support : Objectdecoder_support : Objectmotion_vector : Vectordecoder_error : Object

(from Proxy)

<<Interface>>

Post_processing(from Proxy)

YUV2RGB(from Proxy)

RGB2YUV(from Proxy)

AudioCodec

algoritm : Stringbit_rate : Integer

(from Proxy)

<<Interface>>

ImageCodec(from Proxy)

FileFormat(from Proxy)

MultimediaControl

V.P.1 = (MPEG-4-Level-0) XOR (MPEG-4-Level-1) XOR (MPEG-4-Level-2) XOR (MPEG-4-Level-3) XOR (H.263)

V.P.2 = (GSM 1) XOR (GSM 2) XOR (AMR)

GSM 2 {Variant}(from Proxy)

Mobile device

Mobile device

Mobile device

Feedback signal

analyzer

Gateway

Proxy

Video server

Variability of a proxy architecture for real-time videoin mobile devices




33

Variation Point 1: related to the interface VideoCodec.Depending on the encoding level: picture size, image quality, bit rate and so on, a specific video codec will be chosen. In this case the algebraic expression is:

VP1 = (MPEG-4-Level-0) XOR (MPEG-4-Level-1) XOR (MPEG-4-Level-2) XOR (MPEG-4-Level-3) XOR (H.263)

Variation Point 2: related to the interface AudioCodec, with similar functionality to the VideoCodec. Depending on the coding algorithm or bit rate used, the audio codec will be chosen. The algebraic expression for this variation point is:

VP2 = (GSM 1) XOR (GSM 2) XOR (AMR)

Variability modeling of the proxy RT video system




34

Proxy RT video product derivation

VideoCodec

- header : String- level : Integer- picture_size : Integer- image_quality : Integer- max_bit_rate : Integer- encoder_support : Object- decoder_support : Object- motion_vector : Vector- decoder_error : Object

(from Proxy)

<<Interface>>

Post_processing(from Proxy)

YUV2RGB(from Proxy)

RGB2YUV(from Proxy)

AudioCodec

- algoritm : String- bit_rate : Integer

(from Proxy)

<<Interface>>

ImageCodec(from Proxy)

FileFormat(from Proxy)

MultimediaControl

MPEG-4-Level-3 GSM 1

D1 = MPEG-4-Level-3D2 = GSM 1

2 VP -> 15 ProductConfigurations

Variants chosen:MPEG-4 & GSM 1




35

COVAMOF: ConIPF Variability Modeling Framework (Bosch et al.)

CVV: COVAMOF Variability View: Variability view of the PF. Variation points constitute a view of the variability in the PF.




36

COVAMOF: ConIPF Variability Modeling Framework (Bosch et al.)

COVAMOF variability realization

Variation Point {Variants, Rationale, Realization}




37

• Constitutes a big problem when the number of VPbecomes unmanageable, specially in industrialsettings

• Each VP is characterized by one or more variantsand each variant can hold different values

• Dependencies between VPs introduce a levelof complexity

• The lack of tools is a barrier

Variability Management




38

PLA for Web SystemsMotivation Market Requirements

Time

Func

tiona

lity

ApplicationDevelopment

FamilyDevelopment

TotalDevelopment

t1 t2 t3

TacticDevelopmentGuided byApplications

StrategicDevelopmentGuided by theDomain

Mar

ketP

ress

ure



39

Users demand quick development of Web Products

Different technologies involved(e.g.: HTML, XML, PHP, JSP, WS, Portlets, Servlets)

Frequent changes in products

Short time to market

Challenges



PLA for Web Systems

40

Facilitate maintenance and evolution processes

Flexible designs for supporting the variability ofproducts

Quick reaction for evolving products

Decrease time-to-market of products

Current Needs



PLA for Web Systems

41

Development of flexible and scalablesoftware architectures

Incorporate variability mechanisms

Provide Product Family support

Product derivation & product configuration facilities

Define flexible production plans with reusable assets

Goals



PLA for Web Systems

42

Strategies we can adopt

Complete PLA approachDomain Engineering

Lightweight PLA approachCode analysis tools

Reverse Engineering



PLA for Web Systems

43

Current research issues in the URJC



PLA for Web Systems

• PL process:• Lightweight PL approaches• Adaptation to include Web Services

• Architecting:• Scalable software architectures• Adaptation to WS development• Variability implementation issues



PLA for Web SystemsLightweight Product Line Approach

Semi-automaticanalysis

Manual integrationprocess

Variability & Commonalityanalysis

Reusableassets

45

Asset comparison with VisualDiff Tool



PLA for Web Systems

46

Factorization process

Identification ofpotential common &variable codeparts



PLA for Web Systems

47

Variability Analysis Tool (A PHP Parser)



PLA for Web Systems

48

HTML BODY

<TABLE>BORDER ALIGN

COLOR SPACING

COLS

ROWS

<FORM>

JavaScript Detect Resolution

Check Browser

COLOR Font

IE Netscape

Menu



PLA for Web SystemsVariatibility in Web Assets

49

Variants in the “DataBaseLayer”component

SELECT string FROM tableodbc_exec($connection, $query)mysql_query(($query, $connection)

Databasecomponent

Databasetype

Databaseaccess

Databaseoperation

Databaseresult

Ms-AccessMy-SQL

odbc_connect (dsn, user, passwd)mysql_connect(host, user, passwd)

odbc_fetch_row ($result)mysql_fetch_row($result)mysql_result($result, row, field)odbc_result($result, field)



PLA for Web Systems

50

20%

50%

30%

General PlatformE-LearningEnvironmental Observatory

http://www.biodiversidad.urjc.esBio-diversityWeb Platform2001-2003

Built with theLW-PL

Only a subsetwas analyzed



PLA for Web Systems

51

Some results from the Environmental Observatory Product

EO witout PL

Hours/man

240 (EO)

EO withInformal reuse

EO using LW-PL

120 (EO)

56(EO)

PL Set-up

(2 men)120

Componentdeveloment

150

Assets fromE-Learning

60



PLA for Web Systems

52

Issues not supported in the Web PL



PLA for Web Systems

• Support for single & composite Web Services

• Alternatives for binding WS

• Service discovery & selection methods

• Variability information suitable for WS development

53

Goals for moving to a service-based PL



PLA for Web Systems

Support for web service composition

Composition issues defined initially at design andimplementation phases

Include a service-oriented engineering approachinside the PL process

Adecuate variability information support as a naturalevolution from the variation points described in the web PL



PLA for Web SystemsLW-PL process adapted for Web Services

New

New

55

Context-aware architectures for WS



PLA for Web Systems

“a system is context-aware if it uses context to providerelevant information and/or services to the user, whererelevancy depends on the user’s task”. (Dey & Abowd, 1999)

Web services can use context information for:

• Discover other services and resources in the network• Incorporate user’s preferences for modifying the current context• Plan alternatives depending on the conditions of the context

56

Context-aware systems



PLA for Web Systems

Web services applicationscan employ context information, user preferences and/orquality attributes for matchingsimilar services from differentproviders which are distributedacross the network

57

Context-aware architectures for WS A scalable SOA approach



PLA for Web Systems

Each CM module manages

the input to the system,

which in same cases is related

to physical sensors

or particular devices.



PLA for Web SystemsA basic Context-aware architecture for WS

Customizer: Initializes thecontext and user preferencesMatcher: Checks for changesin the current contextPolicies: For selecting newcontexts

Changes in the executionof the system when contextinformation is modifiedin the client-side, representsa reactive approach. In a pro-active approachwe should be able to changethe context by discoveringnew services during run-time (server side).

59

Varibility description for service composition



PLA for Web Systems

Orchestration model: Defines alternatives for the sequence of activitiesthat happen during the execution of the service.

Service selection: Different binding alternatives can be defined withspecific variation points for selecting between different services.

Exception handling: Different exceptions can be treated during theexecution of a service. Several exceptions can be managed with specificvariants.

Quality factors: A list of predefined quality factors can be used to selectthe best available service during the execution of the system. A variationpoint can be defined to support this feature.

60

Designing composite services



PLA for Web Systems



PLA for Web Systems

Dynamic reconfiguration of services

The automatic reconfiguration of the context adding or removingcomponents (services), constitutes a big challenge for context-awaresystems and in particular for service-oriented systems.

A variable can be stored and checked periodically to know if thecontext has changed or if a new service has been selected.

A restart() function in the CM-SOS initiates a new service with thenew URL.

In the case of composite services we need to identify which sub-servicewill be replaced by the new one



PLA for Web Systems


Can BPEL4WS/1.1 manage the service reconfiguration?

• The BPEL <variables> section to know if conditions have changed• Check conditions and <invoke> the new service• Endpoint references to assign partner services dynamically

Moving towards WSBPEL 2.0



PLA for Web Systems

BPEL & WSDL

BPEL 1.1 BPEL 2.0

OrchestrationLanguage

WSDL 1.1 WSDL 1.1 WSDL 1.2

Abstract Service

64

Evolution and Extensibility of Variantion Points

•Adding variants and values during execution

•Adding variantion points during execution




65

LW-PLA Lessons Learned

Quick set-up in LW-PLA

Decrease time-to-market of products

Early results

Less complex tasks

Service-oriented apps. introduce complexity



PLA for Web Systems

66

Key aspects to consider

Document core assets

Detailed production plans

Automate customization and derivationprocesses of products (tool support)




PLA for Web Systems

Hope you don’t get sleep during the talk - RCOST - HomePage · Life-cycle of assets ... Nokia...

Documents

Transcript of Hope you don’t get sleep during the talk - RCOST - HomePage · Life-cycle of assets ... Nokia...