software engineering and product-line architectures: problem domain roberto silveira silva filho...

Software Engineering and Software Engineering and Product-line architectures: Product-line architectures:

problem domainproblem domainRoberto Silveira Silva FilhoRoberto Silveira Silva Filho

Department of InformaticsDepartment of InformaticsSchool of Information and Computer SciencesSchool of Information and Computer Sciences

University of California, IrvineUniversity of California, [email protected]@ics.uci.edu

First Edition: March 2nd, revision April 27th 2006First Edition: March 2nd, revision April 27th 2006

22

OutlineOutline

Traditional Software Engineering Traditional Software Engineering Software Engineering for Product Lines (SPL)Software Engineering for Product Lines (SPL) SPL Main issuesSPL Main issues

Feature Interaction and dependenciesFeature Interaction and dependencies BoundingBounding Variability realization techniquesVariability realization techniques

Pub/sub infrastructures product linesPub/sub infrastructures product lines Main issuesMain issues

Variability dimensions (bounding)Variability dimensions (bounding) Feature dependenciesFeature dependencies

33

Single-System Software EngineeringSingle-System Software Engineering

GoalGoal: converting High-level specifications into : converting High-level specifications into low-level code (machine executable)low-level code (machine executable) Usually produces one-of a kind software, to solve a Usually produces one-of a kind software, to solve a

specific problem.specific problem. Traditional software process:Traditional software process:

AnalysisAnalysis DesignDesign ImplementationImplementation TestingTesting DeploymentDeployment MaintenanceMaintenance

44

Single-System Software Engineering: Single-System Software Engineering: General problemGeneral problem

General problemGeneral problem: Map this high-: Map this high-level problem description into level problem description into computer-understandable codecomputer-understandable code Can we divide the problem into Can we divide the problem into

sub-problems?sub-problems? Does the program complies with Does the program complies with

the original specification?the original specification?

Validated/verified high-level problem description

0100010010 00010010 110001010 11100101 00101010

End user End user concerns and concerns and requirementsrequirements

Technology Technology concernsconcerns

Low-level program

Software Product Lines Software Product Lines (SPL)(SPL)

Addresses deficiencies from Addresses deficiencies from single-system software single-system software

engineeringengineering

66

Software Software reusereuse motivation motivation From a software reuse perspective…From a software reuse perspective…

Different software systems are usually developed within Different software systems are usually developed within the same problem domainthe same problem domain Each time a program is developed, solutions are reinvented or at Each time a program is developed, solutions are reinvented or at

least re-implementedleast re-implemented

In a software domain, usually a product family, systems In a software domain, usually a product family, systems have large commonality and little variabilityhave large commonality and little variability For example: software for cell phones and digital cameras, For example: software for cell phones and digital cameras,

middleware, etc.middleware, etc. Variability is defined in terms of hardware and software featuresVariability is defined in terms of hardware and software features

Motivation: how to leverage this commonality in order to Motivation: how to leverage this commonality in order to reduce software development costs?reduce software development costs?

77

Software Software evolutionevolution and and maintenancemaintenance motivation motivation

From a software evolution and maintenance From a software evolution and maintenance perspective… perspective…

Software maintenance is the costly phase in software Software maintenance is the costly phase in software developmentdevelopment

Software needs to change due to:Software needs to change due to: Hardware changesHardware changes Input/output data, changes in functionality set, scale Input/output data, changes in functionality set, scale

requirements [Parnas78]requirements [Parnas78]

Motivation: how to make software easier to change and Motivation: how to make software easier to change and evolve?evolve?

88

Software product line goalSoftware product line goal

““to capitalize on commonality and manage variation in to capitalize on commonality and manage variation in order to reduce the time, effort, cost and complexity of order to reduce the time, effort, cost and complexity of creating and maintaining a product line of similar creating and maintaining a product line of similar software systems”software systems”(*)(*)..

The main focus is on:The main focus is on: Predictive (versus opportunistic) software reuse.Predictive (versus opportunistic) software reuse. Mass customization (versus mass production of a single Mass customization (versus mass production of a single

product)product) And And NOTNOT extensibility or evolution. extensibility or evolution.

Even though, one of my goals is both of them.Even though, one of my goals is both of them.

(*) www.softwareproductlines.com/introduction/concepts.html(*) www.softwareproductlines.com/introduction/concepts.html

99

Software Product Lines Software Product Lines consequencesconsequences

ConsequencesConsequences Short term increase of production costsShort term increase of production costs Followed by long term reduction of development costs Followed by long term reduction of development costs

of new productsof new products Resulting in a change in the way developers think Resulting in a change in the way developers think

about software production [Coplein et al 98]about software production [Coplein et al 98]

FlexibilityFlexibility: Software product lines can better : Software product lines can better accommodate unforeseeable changesaccommodate unforeseeable changes This is not the primary goal as software product lines but we This is not the primary goal as software product lines but we

want to study this pointwant to study this point

1010

When to design a product line?When to design a product line?Cost model [Brooks87] [Coplein et al 98]Cost model [Brooks87] [Coplein et al 98]

Number of family members

Cum

ulat

ive

cost

C0

2*C0

3*C0

4*C0

1 2 3 4

Without product line analysisCost = N*C0

With product line analysisCost = A+N*C1

C0 = cost to develop fromscratchC1 = cost when using existingcommonalitiesA = initial product line development costN = number of members

A

1111

Engineering of Software Product Lines -Engineering of Software Product Lines -General ProblemGeneral Problem

General problemGeneral problem: Map high-level : Map high-level problem description into a family problem description into a family of computer-understandable of computer-understandable code:code: Not only a single program, but a Not only a single program, but a

family of similar programsfamily of similar programs Identify commonalityIdentify commonality Manage variabilityManage variability Choose appropriate variability Choose appropriate variability

realization techniquesrealization techniques

High-level (similar) problem descriptions

0100010010 00010010 110001010 11100101 00101010

End user End user concerns and concerns and requirementsrequirements

Base system Base system (incomplete (incomplete program)program)

Technology Technology concernsconcerns

Program variants – based on different product decisions

Variability

com

mon

ality

1212

Software product line (or domain Software product line (or domain engineering) processengineering) process

Apply SVC (Scope Variability Commonality Analysis)Apply SVC (Scope Variability Commonality Analysis) Select commonalitiesSelect commonalities Select variability pointsSelect variability points parameterizeparameterize

Perform feature dependency and interference analysisPerform feature dependency and interference analysis

Bound variability with respect toBound variability with respect to Range (variability parameter options)Range (variability parameter options) Variability Realization Time (runtime, design time, build time)Variability Realization Time (runtime, design time, build time) The goal is to maximize commonality and manage the variability.The goal is to maximize commonality and manage the variability.

Select appropriate variability realization strategies/techniquesSelect appropriate variability realization strategies/techniques

Open questionsOpen questions How to test it?How to test it? How much variability to define?How much variability to define? How dependencies impact bounding and variability realization choices?How dependencies impact bounding and variability realization choices?

1313

General software product line process General software product line process (a.k.a. domain engineering)(a.k.a. domain engineering)

Requirement AnalysisRequirement Analysis Application domain analysisApplication domain analysis Identify commonalities and Identify commonalities and

variabilityvariability

Feature AnalysisFeature Analysis OptionalOptional MandatoryMandatory ExclusiveExclusive

Feature incompatibilitiesFeature incompatibilities Feature dependenciesFeature dependencies Feature interferencesFeature interferences

Variability boundingVariability bounding Restrict variablesRestrict variables Decide binding timeDecide binding time

Runtime, build time, design timeRuntime, build time, design time

ImplementationImplementation ComponentsComponents FrameworksFrameworks AspectsAspects othersothers

Manage dependencies and Manage dependencies and interferencesinterferences

1414

Result of domain engineering (design)Result of domain engineering (design)

Feature diagrams describing core, optional and Feature diagrams describing core, optional and exclusive featuresexclusive features

Commonalities and variability: decision modelCommonalities and variability: decision model

Feature dependency and interference diagramsFeature dependency and interference diagrams

Documents that map features to componentsDocuments that map features to components Kernel components (mandatory)Kernel components (mandatory) Optional components (optional or exclusive)Optional components (optional or exclusive) Selected variability realization techniquesSelected variability realization techniques

Main Research Main Research Challenges in SPLChallenges in SPL

1616

Main research challengesMain research challenges Identifying commonalities and variability:Identifying commonalities and variability:

SVC analysisSVC analysis Essential analysisEssential analysis Adaptive OO programmingAdaptive OO programming

Harnessing Feature interdependenciesHarnessing Feature interdependencies Runtime and usage dependencies between features themselvesRuntime and usage dependencies between features themselves..

Variability Bounding TimeVariability Bounding Time Deciding how much variability is needed – the more variability, the Deciding how much variability is needed – the more variability, the

harder to develop the infrastructure becomesharder to develop the infrastructure becomes

Choosing the appropriate Variability realization techniquesChoosing the appropriate Variability realization techniques

Generative Programming: Automation of the SPL processGenerative Programming: Automation of the SPL process The goal is to go from high-level models to application-specific codeThe goal is to go from high-level models to application-specific code

1717

Main research challenges (cont.)Main research challenges (cont.) Feature modularizationFeature modularization

Features are hard to modularize (separation of concerns)Features are hard to modularize (separation of concerns)

N-to-m mapping between features and their implementation (software N-to-m mapping between features and their implementation (software entities)entities)

Modules interdependencies or couplingModules interdependencies or coupling

Feature interaction resolutionFeature interaction resolution Different features may have components in commonDifferent features may have components in common

Feature interferenceFeature interference: : Features may interfere with one another in Features may interfere with one another in unpredictable ways [Cameron, Velthuijsen 93]unpredictable ways [Cameron, Velthuijsen 93]

Crosscutting featuresCrosscutting features: a feature implementation is spread through : a feature implementation is spread through many code fragments throughout different componentsmany code fragments throughout different components

Feature dependencies or Feature dependencies or couplingcoupling

[Lee and Kang’04][Lee and Kang’04]

Features depended on one Features depended on one another in different ways.another in different ways.

1919

Main sub product of a feature-Main sub product of a feature-oriented analysisoriented analysis

Set of featuresSet of features OptionalOptional MandatoryMandatory ExclusiveExclusive

Features relationshipsFeatures relationships Feature diagram (aggregation, specialization)Feature diagram (aggregation, specialization)

Feature dependenciesFeature dependencies Dependencies diagramDependencies diagram

2020

Main Types of Feature Dependencies Main Types of Feature Dependencies [Lee and Kang’04][Lee and Kang’04]

Usage dependencyUsage dependency: features depend on sub-features : features depend on sub-features for its implementationfor its implementation

Modification dependencyModification dependency: the behavior of a feature is : the behavior of a feature is modified by the presence of another feature.modified by the presence of another feature.

Activation dependencyActivation dependency Exclusive activationExclusive activation: features cannot be active at the same time: features cannot be active at the same time Subordinate activationSubordinate activation: one feature depends on a sub-feature: one feature depends on a sub-feature

ConcurrentConcurrent: subordinate features must be active at the same time: subordinate features must be active at the same time SequentialSequential: features must be activated in a proper order.: features must be activated in a proper order.

2121

Dependencies IssuesDependencies Issues Those dependencies tend to be hard-coded in the componentsThose dependencies tend to be hard-coded in the components

Hindering the evolution and variability of the systemHindering the evolution and variability of the system Resulting in entangled codeResulting in entangled code Coupling between featuresCoupling between features

Solution [Lee and Kang’04]Solution [Lee and Kang’04] Identify the inter-dependencies in the design phaseIdentify the inter-dependencies in the design phase Separate the Separate the activation dependenciesactivation dependencies from the components applying: from the components applying:

ProxyProxy Activation ManagerActivation Manager FactoriesFactories

Those solutions above do not address all the fundamental Those solutions above do not address all the fundamental dependencies but mainly address activation dependenciesdependencies but mainly address activation dependencies

They introduce extra overhead, and require variation points to be They introduce extra overhead, and require variation points to be identified earlier in the designidentified earlier in the design

2222

Feature-specific versus Feature-specific versus fundamental dependenciesfundamental dependencies

Feature-specific dependenciesFeature-specific dependencies are those that appear as a are those that appear as a consequence of the system design and the extra features consequence of the system design and the extra features supported.supported. They can be addressed by some of the techniques proposed by [Lee They can be addressed by some of the techniques proposed by [Lee

and Kang’04]and Kang’04]

Fundamental dependenciesFundamental dependencies are a consequence of the problem are a consequence of the problem domain and cannot be eliminated by reengineering the design.domain and cannot be eliminated by reengineering the design. They are common to the problem and are hard to be avoidedThey are common to the problem and are hard to be avoided For example, in a content-based pub/sub domain, the subscription will For example, in a content-based pub/sub domain, the subscription will

always depend on the event format.always depend on the event format.

Dependencies identification is a sub product of essential problem Dependencies identification is a sub product of essential problem analysis (when applied to domain engineering)analysis (when applied to domain engineering)

2323

Dependencies characterizationDependencies characterization Fundamental dependencies Fundamental dependencies

related to certain kinds of couplingrelated to certain kinds of coupling

A change in a fundamental dimension affects other dimensions A change in a fundamental dimension affects other dimensions preventing reuse of components in that dimension as they are.preventing reuse of components in that dimension as they are. ExampleExample: a change in the event model, implies in updating the : a change in the event model, implies in updating the

subscription and routing dimensions (and their components)subscription and routing dimensions (and their components)

Those dependencies are hard to be isolated from the features Those dependencies are hard to be isolated from the features and their components, which may result in:and their components, which may result in: Feature interactionFeature interaction

Can be caused by: shared components (between two or more features) Can be caused by: shared components (between two or more features) with different environmental assumptionswith different environmental assumptions

Crosscutting featuresCrosscutting features Different concerns result in code fragments that are scattered over Different concerns result in code fragments that are scattered over

different variation points.different variation points.

Feature Variability RealizationFeature Variability Realization

The component-based approachThe component-based approach

Features are implemented around Features are implemented around existing variation pointsexisting variation points

by applying CBSE or OO programmingby applying CBSE or OO programming

2525

Result of domain engineering Result of domain engineering (implementation)(implementation)

Common (mandatory) features

Components that Implement optional and/orexclusive features

Variation points

Base implementation

2626


Component-based approachComponent-based approachone feature one feature many components many components

Feature A

Inter-module dependency

Components interact with one another to Components interact with one another to implement a featureimplement a feature 1-to-n feature-component mapping1-to-n feature-component mapping Inter-module dependenciesInter-module dependencies

Overall modularization Overall modularization problem in traditional CBSEproblem in traditional CBSE

2828

Modularization IssuesModularization Issues

Common features are usually not designed in a Common features are usually not designed in a modular waymodular way Resulting in architectures that are hard to evolveResulting in architectures that are hard to evolve

1 feature = many modules (sub-components)1 feature = many modules (sub-components) Modules inter-dependencies are usually hard-coded Modules inter-dependencies are usually hard-coded Difficulties in the reuse of modulesDifficulties in the reuse of modules Makes system more susceptible to feature interaction Makes system more susceptible to feature interaction

problem.problem.

Feature interaction Feature interaction problemproblem

See [Cameron, Velthuijsen 93]See [Cameron, Velthuijsen 93]

Workshop on Feature Interaction (FIW)Workshop on Feature Interaction (FIW) since 2000 since 2000

Becoming: Workshop on Aspects, Becoming: Workshop on Aspects, Dependencies and Interaction ADI’2006Dependencies and Interaction ADI’2006

3030

Feature Interaction definitionFeature Interaction definition

Features are implemented by different Features are implemented by different componentscomponents Those components are reused in different contextsThose components are reused in different contexts Features augment existing framework or base code, Features augment existing framework or base code,

sharing resources, code, components and so onsharing resources, code, components and so on

Additionally, features may depend on one Additionally, features may depend on one anotheranother

Features may need to co-exist in a certain Features may need to co-exist in a certain configuration of the softwareconfiguration of the software

3131

Feature interactionFeature interaction


Feature AFeature B

N-to-m mapping between components and featuresN-to-m mapping between components and features Results in shared components (components used in more than one feature)Results in shared components (components used in more than one feature) Different timing, control and synchronization assumptions on shared Different timing, control and synchronization assumptions on shared

components may result in unpredictable behavior and side-effectscomponents may result in unpredictable behavior and side-effects

Shared componentsFeature B componentsFeature A components

3232

Crosscutting featuresCrosscutting features

Common (mandatory) featuresCommon (mandatory) features

Feature AFeature B

Shared components need to be tailored to each featureShared components need to be tailored to each feature A feature concern implementation is spread (or crosscuts) throughout A feature concern implementation is spread (or crosscuts) throughout

many componentsmany components

Perfect modularization (behavior independent of feature)

Feature B codeFeature A code

3333

Crosscutting features, Coupling Crosscutting features, Coupling and Cohesionand Cohesion

CouplingCoupling is the measure of the intensity of the relation between two or is the measure of the intensity of the relation between two or more components.more components. Coupling is inevitable but must be minimized to improve modularity or separation Coupling is inevitable but must be minimized to improve modularity or separation

of concernsof concerns

CohesionCohesion is a measure of how related to each other are the operations or is a measure of how related to each other are the operations or functionality implemented in a component. functionality implemented in a component. ““One component, one concern”One component, one concern” is the optimal case. is the optimal case.

Crosscutting features:Crosscutting features: When concerns from a single feature are spread over different componentsWhen concerns from a single feature are spread over different components Resulting in many components implementing more than one feature concernResulting in many components implementing more than one feature concern

Crosscutting concerns usually originate crosscutting features, and may Crosscutting concerns usually originate crosscutting features, and may originate feature interference.originate feature interference.

3434

Feature Feature Concern Concern Implementation: Implementation: ideal vs. real cases ideal vs. real cases

featurefeature

Component AComponent A

Ideal caseIdeal case: “one concern one component”: “one concern one component”

featurefeature

Concern AConcern A Component AComponent A

Crosscutting concernsCrosscutting concerns: “one concern many components”: “one concern many components”

Component BComponent B

coupling

Component BComponent B

coupling

CrosscuttingConcern:What to dowith it?

coheseComponent:

All methodswith respect to thecomponent.

Concern BConcern B

Concern AConcern A

Concern BConcern B

3535

Feature dependenciesFeature dependencies

Feature AFeature A

Feature EFeature E

Feature BFeature B

Feature CFeature C

Feature DFeature D

Feature GFeature G

Feature ZFeature Z

Feature WFeature W

• Features may depend on one anotherFeatures may depend on one another• They can also be mutually exclusive (incompatible)They can also be mutually exclusive (incompatible)

Feature KFeature K

MutuallyMutually exclusive exclusive

MutuallyMutually exclusive exclusive

XORXOR

XORXOR

ANDAND

OROR

3636

Feature interferenceFeature interference

DefinitionDefinition: Feature interference [Cameron and : Feature interference [Cameron and Velthuijsen 93]Velthuijsen 93] Due to shared components, the integration of two or more Due to shared components, the integration of two or more

features result in unpredictable side-effects to the resulting features result in unpredictable side-effects to the resulting systemsystem

In other words, the presence of one feature in the architecture In other words, the presence of one feature in the architecture configuration interferes with the behavior of another feature. configuration interferes with the behavior of another feature. Therefore, changes in this feature also impacts the interfered Therefore, changes in this feature also impacts the interfered features and vice-versa.features and vice-versa.

Feature interaction and crosscutting features may lead to Feature interaction and crosscutting features may lead to feature interferencefeature interference

3737

Feature interaction and AOPFeature interaction and AOP ““AOP composition addresses the fragmentation problem occurring AOP composition addresses the fragmentation problem occurring

in OO frameworks, where adding new variation points usually in OO frameworks, where adding new variation points usually results in the proliferation of “little classes and methods” and thus in results in the proliferation of “little classes and methods” and thus in the excessive increase of complexity” [Kzarnecky and Eisenecker the excessive increase of complexity” [Kzarnecky and Eisenecker 00]00]

Maps one feature to one aspect which is automatically weaved in Maps one feature to one aspect which is automatically weaved in the base code.the base code. Significantly reduces entanglementSignificantly reduces entanglement Can be used to better control footprintCan be used to better control footprint Adds flexibility to the systemAdds flexibility to the system Copes with the incremental developmentCopes with the incremental development

AOP alone AOP alone may notmay not solve feature interference nor interaction solve feature interference nor interaction problems. problems.

3838

AOP and crosscutting featuresAOP and crosscutting features

Common (mandatory) featuresCommon (mandatory) features

Aspect AAspect B

Feature BFeature A

One feature One feature one aspect one aspect Inter-component communication is moved to Inter-component communication is moved to insideinside the aspects the aspects

Inter-component communication is

moved to the aspect-level, being cohese in

a single class

Automatic Weaving of Aspects into the components

BoundingBoundingAnswering the questions:Answering the questions:

What dimensions to fix and which ones to vary?What dimensions to fix and which ones to vary?

What are the variability dimensions limits?What are the variability dimensions limits?

4040

Bounding issuesBounding issues The more flexible an infrastructure becomes, the harder The more flexible an infrastructure becomes, the harder

to implement it becomes, due to:to implement it becomes, due to: Feature interactionFeature interaction Dependencies (coupling and cohesion issues)Dependencies (coupling and cohesion issues)

Variability must be restricted to the essential amount Variability must be restricted to the essential amount required by the domain.required by the domain.

How to determine this amount?How to determine this amount? A coupling/dependency analysis may help in identifying the most A coupling/dependency analysis may help in identifying the most

“problematic” dimensions!!!“problematic” dimensions!!! A problematic dimension is that that impacts more dimensionsA problematic dimension is that that impacts more dimensions A rule of thumb is to defer bounding as much as possibleA rule of thumb is to defer bounding as much as possible

Product line architectures Product line architectures and pub/sub infrastructuresand pub/sub infrastructures

Specific Problem characterizationSpecific Problem characterization

4242

Product line architectures and Product line architectures and middlewaremiddleware

DefinitionDefinition: Middleware is a layer of software : Middleware is a layer of software between the OS/Network and the applicationbetween the OS/Network and the application

It provides specialized services to the It provides specialized services to the development of distributed application, freeing the development of distributed application, freeing the programmer from low-level concerns.programmer from low-level concerns. Communication and location transparenciesCommunication and location transparencies Communication guaranteesCommunication guarantees Quality of servicesQuality of services

Different applications require different services Different applications require different services from the middlewarefrom the middleware

4343

Product line architectures for Product line architectures for publish/subscribe infrastructurespublish/subscribe infrastructures

Pub/sub infrastructures (middleware) provide Pub/sub infrastructures (middleware) provide asynchronous message exchange between asynchronous message exchange between distributed peersdistributed peers Basic rolesBasic roles: publishers, subscribers, infrastructure: publishers, subscribers, infrastructure Basic elementsBasic elements: messages and subscriptions: messages and subscriptions

Besides the basic pub/sub mechanism, different Besides the basic pub/sub mechanism, different applications need:applications need: specialized features (ex. advanced event processing, specialized features (ex. advanced event processing,

event source discovery, push/pull notifications)event source discovery, push/pull notifications) qualities of service (ex. guaranteed event delivery)qualities of service (ex. guaranteed event delivery)

4444

Application-specific features and Application-specific features and variability spectrum (examples):variability spectrum (examples):

SubscriptionSubscription Sequence detection, interval operations, pattern matching, Sequence detection, interval operations, pattern matching,

abstraction, rulesabstraction, rules Content-based, topic-based, channel-based filteringContent-based, topic-based, channel-based filtering

NotificationNotification Push and pullPush and pull

ProtocolProtocol User-levelUser-level: Mobility, peer advertisement/discover: Mobility, peer advertisement/discover Infrastructure levelInfrastructure level: federation, P2P: federation, P2P

ResourceResource Centralized, P2P, federatedCentralized, P2P, federated

EventsEvents Record, tuples, objectsRecord, tuples, objects Guaranteed deliveryGuaranteed delivery

4545

Feature DiagramFeature Diagram

Pub/ sub infrastructure

Routing EventNotification Subscription Timing Resource Protocol

Topic-based<<optional>>

Channel-based<<optional>>

Content-based<<optional>>

Tuples<<exclusive>>

Object<<exclusive>>

Record<<exclusive>> Content operator

<<optional>>

Sequence operator<<optional>>

Basic<<optional>>

Advanced<<optional>>

User<<optional>>Infrastructure

Content filter<<optional>>

Topic filter<<optional>>

Abstraction<<optional>>

Rules<<optional>>

Pattern<<optional>>

Time operators<<optional>>

Sequence detection<<optional>>

Push<<optional>>

Pull<<optional>>

Casual order<<exclusive>>

Total order<<exclusive>>

Client side<<exclusive>>

Service-side<<exclusive>>

P2P<<exclusive>>

Peer-to-Peer<<exclusive>>

Hierarchical<<exclusive>>

mobility<<optional>>

source discovery<<optional>>

advertising<<optional>>

account management<<optional>>

Filtering<<optional>>

Plain Text<<exclusive>>

Repeated events<<optional>>

Aggregation<<optional>>

UML notation of main features, and their specializationsUML notation of main features, and their specializations Boxes represent featuresBoxes represent features

First level denotes essential features, with the exception of infrastructure filteringFirst level denotes essential features, with the exception of infrastructure filtering <<optional>> denotes optional features (non-essential)<<optional>> denotes optional features (non-essential) <<exclusive> denotes exclusive or of the features tagged with that stereotype.<<exclusive> denotes exclusive or of the features tagged with that stereotype.

<<optional>> == OR<<optional>> == OR <<mandatory>> == AND<<mandatory>> == AND <<exclusive>> == XOR<<exclusive>> == XOR

4646

Feature Diagram (zoom left)Feature Diagram (zoom left)Pub/ sub infrastructure





Tuples<<exclusive>>

Object<<exclusive>>


<<optional>>


Basic<<optional>>






Rules<<optional>>

Pattern<<optional>>



Push<<optional>>

Pull<<optional>>





P2P<<exclusive>>












4747

Feature Diagram (zoom right)Feature Diagram (zoom right)Pub/ sub infrastructure





Tuples<<exclusive>>

Object<<exclusive>>


<<optional>>


Basic<<optional>>






Rules<<optional>>

Pattern<<optional>>



Push<<optional>>

Pull<<optional>>





P2P<<exclusive>>












4848

Dependency DiagramDependency Diagram

Dashed lines (standard UML) represent fundamental Dashed lines (standard UML) represent fundamental dependenciesdependencies Changes in one dimension, deeply impacts other dimensionsChanges in one dimension, deeply impacts other dimensions Dependencies can be of different kindsDependencies can be of different kinds

I mean publication

filtering

Routing

EventNotification

Subscription

Timing Resource Protocol

Infrastructure Prot

Pub/ sub infrastructure

User Prot<<optional>>

Content operator<<optional>>



4949

Fundamental dependencies in Fundamental dependencies in publish/subscribepublish/subscribe

Publishers and subscribers in generalPublishers and subscribers in general Implicit contract between publishers and subscribersImplicit contract between publishers and subscribers

subscribers need to know what to subscribe tosubscribers need to know what to subscribe to publishers need to agree in a common representation of the informationpublishers need to agree in a common representation of the information

Results on fundamental dependencies:Results on fundamental dependencies: Subscription language content operators Subscription language content operators event format event format Subscription language sequence operators Subscription language sequence operators timing timing Subscription language Subscription language routing algorithms routing algorithms Routing algorithms Routing algorithms event format event format

Content-based, topic-based routingContent-based, topic-based routing Routing algorithms Routing algorithms timing guarantees timing guarantees Routing algorithms Routing algorithms subscription subscription

5050

Dependencies among application-Dependencies among application-specific features (examples)specific features (examples)

Mobile protocol Mobile protocol pull notification pull notification Peer-to-peer publishing Peer-to-peer publishing peer location protocol peer location protocol Content-based filtering Content-based filtering content-based router content-based router

structured event format structured event format Temporal logic Temporal logic timing protocols for routing timing protocols for routing

eventsevents And so on…And so on…

5151

Open questionsOpen questions Are there fundamental feature interference in pub/sub domain?Are there fundamental feature interference in pub/sub domain?

Surely, there are feature dependenciesSurely, there are feature dependencies

Can they be addressed by some approach?Can they be addressed by some approach? AOP alone is not enough. AOP alone is not enough.

It only modularizes crosscutting concernsIt only modularizes crosscutting concerns Is Configuration management sufficient?Is Configuration management sufficient?

No it only manages dependencies and inconsistenciesNo it only manages dependencies and inconsistencies Can a combined approach address it?Can a combined approach address it?

MaybeMaybe Can a redesign or use of other paradigm solve the problem?Can a redesign or use of other paradigm solve the problem?

Maybe a multi-agent approach with late-binding can helpMaybe a multi-agent approach with late-binding can help This will depend on the categorization of the dependencies. Some can be This will depend on the categorization of the dependencies. Some can be

solved with late binding, some with auxiliary components, and so on.solved with late binding, some with auxiliary components, and so on.

YANCEES as a possible YANCEES as a possible solution to the problemsolution to the problem

Traditional OO approachTraditional OO approach

It has limitations too…It has limitations too…

5353

YANCEES Solution to variability YANCEES Solution to variability realizationrealization

Isolate (decouples) dependencies using design patterns:Isolate (decouples) dependencies using design patterns: AdaptersAdapters FactoriesFactories Configuration managersConfiguration managers

Provide variability in different fundamental points using different strategies:Provide variability in different fundamental points using different strategies: subscription:subscription: Plug-ins and extensible languages Plug-ins and extensible languages input filtering:input filtering: Input and output Filters Input and output Filters routing:routing: Adapters to existing infrastructure and new routing components Adapters to existing infrastructure and new routing components protocol plug-insprotocol plug-ins: Additional protocol and static plug-ins to integrate extra : Additional protocol and static plug-ins to integrate extra

functionalityfunctionality event representation:event representation: using XML. using XML.

Runtime binding of plug-insRuntime binding of plug-ins

Startup binding of components using a builderStartup binding of components using a builder

Built on top of a common pub-sub core (framework)Built on top of a common pub-sub core (framework)

5454

YANCEES Approach DiagramYANCEES Approach Diagram

YANCEES pub/sub

Pub/ subcore

Publisher

plug-in prot

Client stub

plug-infilter filter

filter

plug-in

plug-in plug-in

Subscriber

Client stub

plug-in

plug-in

filter

NotificationService

NotificationService

Producer 1

Producer 2

Producer 3

Consumer A

Consumer B

event

event

event

subscribe

subscribe

notification

notification

5555

YANCEES solution to YANCEES solution to dependencies managementdependencies management

Configuration managersConfiguration managers

Allows the specification of optional componentsAllows the specification of optional components

Checks for dependenciesChecks for dependencies

Builds YANCEES instances at startup timeBuilds YANCEES instances at startup time Additional variability at runtime by using factoriesAdditional variability at runtime by using factories

Plug-ins are allocated over demandPlug-ins are allocated over demand New components can be installed at runtimeNew components can be installed at runtime

5656

YANCEES shortcomingsYANCEES shortcomings Initial design limits the configurability to the prescribed variation Initial design limits the configurability to the prescribed variation

pointspoints

Too many adaptation points can make the development of extensions Too many adaptation points can make the development of extensions hardhard Need to adapt different pointsNeed to adapt different points Interconnect those componentsInterconnect those components Manage conflicts and inter-dependenciesManage conflicts and inter-dependencies

Complex configurationComplex configuration: different components implement a feature, : different components implement a feature, and must be present at the same timeand must be present at the same time

Dependencies examplesDependencies examples Variability-realization specific dependenciesVariability-realization specific dependencies: d: due to the use of filters ue to the use of filters

and plug-ins: and plug-ins: activationactivation, , sequencesequence and and useuse dependencies in the dependencies in the components are hard to manage and may cause different errorscomponents are hard to manage and may cause different errors

FundamentalFundamental: : event format is crosscutting and cannot be easily changed event format is crosscutting and cannot be easily changed without impacting other parts of the systemwithout impacting other parts of the system

5757

Accidental dependencies in Accidental dependencies in YANCEES (result of the design)YANCEES (result of the design)

Implementation-specific issues:Implementation-specific issues:

Use of filtersUse of filters: sequential dependencies of the input : sequential dependencies of the input and output filters: and output filters: order matters and one filter can interfere other filtersorder matters and one filter can interfere other filters

Use of plug-ins:Use of plug-ins: need to integrate different variation need to integrate different variation points points Concurrent dependencies of subscription plug-insConcurrent dependencies of subscription plug-ins

A sequence plug-in depends on two or more filters activated in A sequence plug-in depends on two or more filters activated in parallelparallel

Use dependencies between static plug-ins and protocolsUse dependencies between static plug-ins and protocols Example: P2P publish, peer discovery and filtersExample: P2P publish, peer discovery and filters

5858

YANCEES example - impromptuYANCEES example - impromptu

topicfilter

push

Subscribers

Publishers

adapter

topic-based core

YANCEESserver onpeer B

redirectorfilter

topicfilter

push

Publishers

adapter

topic-based core

YANCEESserver on peer A

redirectorfilter

Peerpublisher

Peerpublisher

mDNSprotocolclient

mDNSprotocolclient

Subscribers

plug-insadaptersprotocols

leg

en

d

filters

FundamentalFundamentaldependencydependency

Use dependencyUse dependency

Use dependencyUse dependency

5959

Feature Interaction in Feature Interaction in pub/sub domainpub/sub domain

In pub/sub in generalIn pub/sub in general Due to the fundamental domain dependenciesDue to the fundamental domain dependencies

Event representation impacts other dimensions such as Event representation impacts other dimensions such as subscription and input filteringsubscription and input filtering

It is not necessarily a feature interference.It is not necessarily a feature interference.

In YANCEES, they can occur due to:In YANCEES, they can occur due to: the sequence dependencies in the input-output filtersthe sequence dependencies in the input-output filters the reuse of lower-level subscription plug-insthe reuse of lower-level subscription plug-ins

For example, same content filter for two different For example, same content filter for two different subscriptionssubscriptions

6060

Crosscutting features in pub/sub Crosscutting features in pub/sub domaindomain

Also come from the fundamental dependencies, Also come from the fundamental dependencies, which impact the overall system implementationwhich impact the overall system implementation

TimingTiming Impacts the way subscription plug-ins and filters are Impacts the way subscription plug-ins and filters are

implementedimplemented

The event representationThe event representation due to the fundamental dependencies, result in concerns due to the fundamental dependencies, result in concerns

spread throughout the components implementationspread throughout the components implementation

General approaches to General approaches to the main problemsthe main problems

Parnas/Dijkstra stepwise refinement Parnas/Dijkstra stepwise refinement A survey of variability realization techniques is presented at: [A survey of variability realization techniques is presented at: [Svahnberg, M., J. Svahnberg, M., J. v. Gurp, et al., v. Gurp, et al., 2005]2005] A description of common dependencies and approaches to minimize their A description of common dependencies and approaches to minimize their impact are presented at [Lee and Kang 2004]impact are presented at [Lee and Kang 2004] Generative programmingGenerative programming Essential Systems AnalysisEssential Systems Analysis AOP for footprint and feature management [Hunleth and Cytron 02] AOP for footprint and feature management [Hunleth and Cytron 02] Adaptive OO programming (AOOP) by [K. Lieberherr 96]Adaptive OO programming (AOOP) by [K. Lieberherr 96] Multi-agent paradigm?Multi-agent paradigm?

6262

Parnas/Dijkstra stepwise refinement [Parnas 76]Parnas/Dijkstra stepwise refinement [Parnas 76]

Sequential completionSequential completion Programs evolve based on Programs evolve based on

existing complete programs existing complete programs (X nodes)(X nodes)

Stepwise refinementStepwise refinement Programs are created based on Programs are created based on

incomplete program incomplete program representations (circles)representations (circles)

Those representations are Those representations are centralcentral

6363

MDA – Model Driven ArchitecturesMDA – Model Driven Architectures

Industry initiative that focus on using software product lines to Industry initiative that focus on using software product lines to address platform-dependent variability:address platform-dependent variability: Hardware, programming language, network protocols, infrastructureHardware, programming language, network protocols, infrastructure Platform independence is the goalPlatform independence is the goal For example: For example:

different platforms: CORBA, RMI, SOA, J2MEdifferent platforms: CORBA, RMI, SOA, J2ME Different languages: Java, C#, C++Different languages: Java, C#, C++

Based on OMG models and architecture such as UML, CORBABased on OMG models and architecture such as UML, CORBA

Prescribes sets of transformations from platform independent to Prescribes sets of transformations from platform independent to platform dependent models and subsequently to source code.platform dependent models and subsequently to source code. Bridge the gap between problem domain model and solution domain Bridge the gap between problem domain model and solution domain

model.model. Application generation from higher-level models, instead of code.Application generation from higher-level models, instead of code.

6464

Managing dependencies using Managing dependencies using design patterns – late bindingdesign patterns – late binding

Generally speaking, Generally speaking, delays the binding time of delays the binding time of dependenciesdependencies..

[Lee and Kang 2004] apply some design patterns to [Lee and Kang 2004] apply some design patterns to isolate dependencies from the components of the isolate dependencies from the components of the system:system: ProxyProxy: isolates components encapsulation activation decisions: isolates components encapsulation activation decisions FactoryFactory: performs dynamic binding based on existing criteria: performs dynamic binding based on existing criteria Activation ManagerActivation Manager: resolves dependencies at runtime.: resolves dependencies at runtime.

This is actually adopted by YANCEESThis is actually adopted by YANCEES

6565

Adaptive OO Programming (AOOP) Adaptive OO Programming (AOOP) [K. LieberherrLieberherr 96]

Finds patterns of essential classes and their interaction, extracting their Finds patterns of essential classes and their interaction, extracting their commonalitiescommonalities Detects common pathsDetects common paths Removes non-essential methods and classesRemoves non-essential methods and classes Keeping only essential methods, classes and relations.Keeping only essential methods, classes and relations. Results in:Results in:

a partial class structure and a partial class structure and a set of constraints that must be satisfied by customizes of a class.a set of constraints that must be satisfied by customizes of a class.

Specific programs are implemented by adding methods and classes to Specific programs are implemented by adding methods and classes to the skeletal, essential representation of the program.the skeletal, essential representation of the program. Mechanism: performs late-binding of methods to classes in OO programsMechanism: performs late-binding of methods to classes in OO programs

In the author’s words…In the author’s words… ““While conventional object-oriented programmers bind methods explicitly to While conventional object-oriented programmers bind methods explicitly to

classes, adaptive programmers delay binding of methods until a class classes, adaptive programmers delay binding of methods until a class structure customizer is provided.”structure customizer is provided.” [K. Lieberherr 96] [K. Lieberherr 96]

6666

Generative ProgrammingGenerative Programming ““Generative programming is about modeling and implementing system Generative programming is about modeling and implementing system

families in such a way that a given system can be automatically generated families in such a way that a given system can be automatically generated from a specification written in one or more textual or graphical domain-from a specification written in one or more textual or graphical domain-specific languages (DSLs) “ [Krzysztof]specific languages (DSLs) “ [Krzysztof]

It proposes a generative model:It proposes a generative model: Initial domain analysis Initial domain analysis domain model domain model Components that implement variability and commonalitiesComponents that implement variability and commonalities Configuration knowledge: dependencies, compatibilities, architecture, assembly Configuration knowledge: dependencies, compatibilities, architecture, assembly

rules…rules… Program generators that integrate the components to produce requirement-Program generators that integrate the components to produce requirement-

specific softwarespecific software

Techniques used by Generative Programming include:Techniques used by Generative Programming include: GenVoca and stepwise refinement [Parnas 76]GenVoca and stepwise refinement [Parnas 76]

Augment a common base program by mixing code together.Augment a common base program by mixing code together. Program generators [Czarnecki et al.]Program generators [Czarnecki et al.]

Apply domain-specific languages to generate codeApply domain-specific languages to generate code Intentional programmingIntentional programming

Use of domain-specific languages to generate domain-specific programsUse of domain-specific languages to generate domain-specific programs

6767

Generative ProgrammingGenerative Programming

Prescribes a domain modelPrescribes a domain model Inter-component dependencies are handled in code Inter-component dependencies are handled in code

fragments that are weaved to the base code to design fragments that are weaved to the base code to design customized componentscustomized components In other words, it does not eliminate the dependencies, only In other words, it does not eliminate the dependencies, only

moves them to another levelmoves them to another level It also does not address the feature dependencies problemsIt also does not address the feature dependencies problems

6868

Essential Systems Analysis Essential Systems Analysis [McMenamin and Palmer, 84][McMenamin and Palmer, 84]

Main conceptsMain concepts Based on structured analysisBased on structured analysis Produce an essential system model that isProduce an essential system model that is

Driven by external and temporal eventsDriven by external and temporal events Technology independentTechnology independent Represent the essential system behavior and Represent the essential system behavior and

responseresponse

Even though designed for single software Even though designed for single software structured design, the idea of technology structured design, the idea of technology independence and essential system behavior is independence and essential system behavior is a key concept we want to usea key concept we want to use

6969

Essential Systems Analysis Essential Systems Analysis [McMenamin and Palmer, 84][McMenamin and Palmer, 84]

Essential analysis will identify the core or common Essential analysis will identify the core or common components of the product family in a way independent components of the product family in a way independent of technologyof technology

Separates essential from non-essential characteristicsSeparates essential from non-essential characteristics

7070

AOP approachAOP approach Basically modularizes cross-cutting concerns, moving Basically modularizes cross-cutting concerns, moving

some dependencies to the meta-level, where they can be some dependencies to the meta-level, where they can be more easily managedmore easily managed

Provides a mechanism for late binding of code Provides a mechanism for late binding of code good for good for footprint managementfootprint management

Example: FACET [Pratap, Hunleth, Cytron 04] Example: FACET [Pratap, Hunleth, Cytron 04] implemented CORBA-NS using AOP horizontal implemented CORBA-NS using AOP horizontal decomposition [Jhang and Jacobsen 2004]decomposition [Jhang and Jacobsen 2004] Focus on footprint managementFocus on footprint management The feature set is tailored at CORBA-NS standard: channel-based The feature set is tailored at CORBA-NS standard: channel-based

routingrouting Dependency management performed by ant.Dependency management performed by ant. Does not explain fundamental dependencies and their role in the Does not explain fundamental dependencies and their role in the

customization of the system.customization of the system.

7171

Multi-agent paradigmMulti-agent paradigm

Components are “intelligent” and perform Components are “intelligent” and perform runtime decisionsruntime decisions

Those decisions are helped by agencies and Those decisions are helped by agencies and auxiliary objectsauxiliary objects

They can be used to perform late-binding, They can be used to perform late-binding, handling some dependency problems using:handling some dependency problems using: ProxiesProxies TradersTraders AgenciesAgencies

Principles in the Product Principles in the Product Line DesignLine Design

Conclusions of the Survey: Conclusions of the Survey: Extracted from the available Extracted from the available

techniquestechniques

7373

Summary of principlesSummary of principles Analysis principlesAnalysis principles

Domain EngineeringDomain Engineering Feature-based modelingFeature-based modeling Identification of commonalities and variabilityIdentification of commonalities and variability

Essential analysis – fundamental dependencies identificationEssential analysis – fundamental dependencies identification Identifies fundamental dependencies and requirements for a program familyIdentifies fundamental dependencies and requirements for a program family

Design principlesDesign principles Stepwise refinement: develop incomplete programs (Parnas)Stepwise refinement: develop incomplete programs (Parnas)

Information hiding of variable dimensions and separation of concernsInformation hiding of variable dimensions and separation of concerns De-coupling and high cohesionDe-coupling and high cohesion Dependency inversionDependency inversion

Use of interfaces to separate abstractions and implementationsUse of interfaces to separate abstractions and implementations OO principles expressed in design patternsOO principles expressed in design patterns

Late binding – dependency resolutionLate binding – dependency resolution Uses environment or configuration parameters to decide what feature to implementUses environment or configuration parameters to decide what feature to implement

Modularization – dependency isolation, information hidingModularization – dependency isolation, information hiding Minimizes dependencies coping with configuration and independent developmentMinimizes dependencies coping with configuration and independent development AOP, AOOP, meta-level programming may help improve some hard dependenciesAOP, AOOP, meta-level programming may help improve some hard dependencies OO may also help OO may also help

7474

The role of dependencies in OO designThe role of dependencies in OO design

Symptoms of bad OO design: rigidity, fragility, immobility and Symptoms of bad OO design: rigidity, fragility, immobility and viscosityviscosity

“ “ What kind of changes cause designs to rot? Changes that introduce new What kind of changes cause designs to rot? Changes that introduce new and unplanned for dependencies. Each of the four symptoms mentioned and unplanned for dependencies. Each of the four symptoms mentioned above is either directly, or indirectly caused by improper dependencies above is either directly, or indirectly caused by improper dependencies between the modules of the software. It is the dependency architecture that between the modules of the software. It is the dependency architecture that is degrading, and with it the ability of the software to be maintained.is degrading, and with it the ability of the software to be maintained.

In order to forestall the degradation of the dependency architecture, the In order to forestall the degradation of the dependency architecture, the dependencies between modules in an application must be managed. This dependencies between modules in an application must be managed. This management consists of the creation of dependency firewalls. Across such management consists of the creation of dependency firewalls. Across such firewalls, dependencies do not propagate.firewalls, dependencies do not propagate.

Object Oriented Design is replete with principles and techniques for building Object Oriented Design is replete with principles and techniques for building such firewalls, and for managing module dependencies. “*such firewalls, and for managing module dependencies. “*

* * Robert C. Martin. Design Principles and Design Patterns, www.objectmentor.comRobert C. Martin. Design Principles and Design Patterns, www.objectmentor.com

7575

OOD Design Principles and RulesOOD Design Principles and Rules

GoalGoal: minimize the rigidity, fragility, immobility and viscosity of OO Design: minimize the rigidity, fragility, immobility and viscosity of OO Design

Principles:Principles: Open Closed PrincipleOpen Closed Principle

A module should be open for extension but closed for modification.A module should be open for extension but closed for modification. Liskov Substitution PrincipleLiskov Substitution Principle

Subclasses should be substitutable for their base classes.Subclasses should be substitutable for their base classes. Dependency Inversion PrincipleDependency Inversion Principle

High-level modules should not depend upon low-level modules. Both should depend upon High-level modules should not depend upon low-level modules. Both should depend upon abstractionsabstractions

Abstractions should not depend upon details. Details should depend upon abstractionsAbstractions should not depend upon details. Details should depend upon abstractions Acyclic Dependencies PrincipleAcyclic Dependencies Principle Law of Demeter or “Principle of Least Knowledge”Law of Demeter or “Principle of Least Knowledge”

"Only talk to your immediate friends". The fundamental notion is that a given object should assume "Only talk to your immediate friends". The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents). as little as possible about the structure or properties of anything else (including its subcomponents).

Functionality RuleFunctionality Rule Boundary-Controller Entity RuleBoundary-Controller Entity Rule Specialization and Generalization RuleSpecialization and Generalization Rule Hierarchical, Modular and Layered RuleHierarchical, Modular and Layered Rule Design by Contract (DBC)Design by Contract (DBC) And others…And others…

7676

The risk of too much flexibilityThe risk of too much flexibility

Flexibility is desirable due to changing requirements and reuseFlexibility is desirable due to changing requirements and reuse However, there is no general solution to the flexibility problem in However, there is no general solution to the flexibility problem in

software engineeringsoftware engineering Too much flexibility is not attainable due to:Too much flexibility is not attainable due to:

Security costsSecurity costs About OpenOffice: “A number of the problems described in the report have to do About OpenOffice: “A number of the problems described in the report have to do

with the basic design of the software. For example, OpenOffice.org does not with the basic design of the software. For example, OpenOffice.org does not perform adequate security checks on the software it runs, the researcher said. perform adequate security checks on the software it runs, the researcher said. And because of the extreme flexibility of the free office suite, there are many ways And because of the extreme flexibility of the free office suite, there are many ways for writers to create malicious macros, the researchers found. “ InfoWorld, August for writers to create malicious macros, the researchers found. “ InfoWorld, August 2006, http://www.infoworld.com/article/06/08/11/HNopenofficesecurity_1.html2006, http://www.infoworld.com/article/06/08/11/HNopenofficesecurity_1.html

Configuration management costsConfiguration management costs Expression of dependencies in the configuration languageExpression of dependencies in the configuration language Management of ‘incompatible’, ‘require’ dependenciesManagement of ‘incompatible’, ‘require’ dependencies Version managementVersion management

Debugging and program comprehension issuesDebugging and program comprehension issues Entanglement, control and data dependencies.Entanglement, control and data dependencies.

Topic ProposalTopic ProposalSome ideas and directionsSome ideas and directions

After talking to Crista.After talking to Crista.

7878

Meeting with Crista 05/18/2006Meeting with Crista 05/18/2006

Option 1: generative approachOption 1: generative approach Build a product line for my own reuse Build a product line for my own reuse speed up software speed up software

development of customized pub/sub systemsdevelopment of customized pub/sub systems Challenges:Challenges:

Problem domain analysis: Determine all possible variabilityProblem domain analysis: Determine all possible variability Management of dependencies and incompatibilitiesManagement of dependencies and incompatibilities Choose the best implementation approachChoose the best implementation approach

EvaluationEvaluation Compare approaches: implementation from scratch, reuse of Compare approaches: implementation from scratch, reuse of

existing systems, and use of the proposed system to build custom existing systems, and use of the proposed system to build custom applicationsapplications

Use the dependency model as a guidance, to explain the Use the dependency model as a guidance, to explain the observations and limitations of each approachobservations and limitations of each approach

Possible issuesPossible issues An AOP implementation already exists: FACET [An AOP implementation already exists: FACET [Pratap, Hunleth, Pratap, Hunleth,

Cytron 04]Cytron 04]

7979

Meeting with Crista 05/18/2006Meeting with Crista 05/18/2006

Option 2: open source product linesOption 2: open source product lines Question: how to build an open source infrastructure that can be Question: how to build an open source infrastructure that can be

extended and customized by other users?extended and customized by other users? Main challenges:Main challenges:

Usability: how can other users learn and extend my model?Usability: how can other users learn and extend my model? Extensibility: How to accommodate unforeseen features?Extensibility: How to accommodate unforeseen features?

EvaluationEvaluation User study (how to evaluate?)User study (how to evaluate?)

In both options (1 and 2) we have:In both options (1 and 2) we have: Product line architecture: components and base frameworkProduct line architecture: components and base framework GUI + constraints = meta programming for automatic code GUI + constraints = meta programming for automatic code

generationgeneration

The incorporation of problem fundamental dependencies as The incorporation of problem fundamental dependencies as guidance in the processguidance in the process

8080

Meeting with André 06/07/2006Meeting with André 06/07/2006 What are the questions I want to answer with my model?What are the questions I want to answer with my model? The role of dependencies in product line designThe role of dependencies in product line design

How fundamental dependencies can help me choose what variability realization How fundamental dependencies can help me choose what variability realization techniques to use?techniques to use?

What kinds of dependencies exist?What kinds of dependencies exist? What dependencies are better addressed by what approach?What dependencies are better addressed by what approach? The result will be a set of dependencies The result will be a set of dependencies forces forces approaches model. approaches model.

By using feature-based domain analysis/engineering, and considering By using feature-based domain analysis/engineering, and considering dependencies, I expect:dependencies, I expect: Better separation of concernsBetter separation of concerns Better design structureBetter design structure A reduction in feature interactionA reduction in feature interaction Better understandability of my product family Better understandability of my product family better extensibility and reuse better extensibility and reuse

What’s conceptually different from FACET?What’s conceptually different from FACET? Broader model, that includes content-based pub/subBroader model, that includes content-based pub/sub A step back: A step back:

conceptual fundamental dependencies as guidance to produce the base systemconceptual fundamental dependencies as guidance to produce the base system Non-fundamental dependencies are secondaryNon-fundamental dependencies are secondary FACET provides a good approach for feature dependency management, testing and FACET provides a good approach for feature dependency management, testing and

weaving, but does not answer more fundamental questions as thoseweaving, but does not answer more fundamental questions as those

8181

My own ideas after meeting with My own ideas after meeting with Redmiles 06/07/2006Redmiles 06/07/2006

On the criteria to be used when defining variability and On the criteria to be used when defining variability and commonalities: the role of dependenciescommonalities: the role of dependencies How fundamental problem dependencies impact the variability of the How fundamental problem dependencies impact the variability of the

system?system? What are the impacts of dependencies in modularization?What are the impacts of dependencies in modularization?

What kinds of dependencies are modularizable and which ones are not?What kinds of dependencies are modularizable and which ones are not?

How to tame dependencies using existing techniques?How to tame dependencies using existing techniques? Get the event-routing-subscription dependency and experiment with:Get the event-routing-subscription dependency and experiment with:

AOPAOP MixingsMixings OOOO Adaptive ProgrammingAdaptive Programming

What if there are restrictions in the set of techniques to be used?What if there are restrictions in the set of techniques to be used? AOP cannot be always used (ex. Palm OS JDK constraints)AOP cannot be always used (ex. Palm OS JDK constraints) Some systems may require traditional structured programming alone Some systems may require traditional structured programming alone

(legacy code)(legacy code)

8282

Meeting with Redmiles 06/07/2006Meeting with Redmiles 06/07/2006

Criteria 1Criteria 1: Use information Hiding as suggested by Parnas: : Use information Hiding as suggested by Parnas: Modularize commonalities hiding concernsModularize commonalities hiding concerns Add variation points around itAdd variation points around it

If I cannot completely modularize the problem with OO, try use AOPIf I cannot completely modularize the problem with OO, try use AOP AOP breaks information hiding.AOP breaks information hiding.

Criteria 2Criteria 2: Try using FSE 2005 approach: Try using FSE 2005 approach DSMs and dependencies as a criteria for aspect definition.DSMs and dependencies as a criteria for aspect definition. Plus the proper code management since information hiding is brokenPlus the proper code management since information hiding is broken

Compare both approaches in a high-level modelCompare both approaches in a high-level model Define a kind of catalog explaining the forces one should consider when Define a kind of catalog explaining the forces one should consider when

selecting one approach or another.selecting one approach or another.

8383

Other insightsOther insights According to Parnas, information hiding, and not the According to Parnas, information hiding, and not the

execution order (flow chart), should be the criteria used execution order (flow chart), should be the criteria used to modularize systemsto modularize systems Modules should depend on one another through a Modules should depend on one another through a useuse relation relation

Matching (eventMatching (event subscription) is a concern of the event subscription) is a concern of the event or of the infrastructure? or of the infrastructure?

Modularization CriteriaModularization Criteria: cohesion and information hiding: cohesion and information hiding If event format varies too much, matching must be moved to the If event format varies too much, matching must be moved to the

eventevent But the criteria must be standardized so the event can know But the criteria must be standardized so the event can know

what to expectwhat to expect Hence, it is hard to isolate the matching criteria and the event Hence, it is hard to isolate the matching criteria and the event

representationrepresentation

8484

Other insights (cont.)Other insights (cont.)

Subscription Subscription event. What information should event. What information should be hidden here? The matching operation should be hidden here? The matching operation should be common to both.be common to both. Matching should be the concern that isolates events Matching should be the concern that isolates events

and subscriptions.and subscriptions.

Can we modularize dependencies? In other Can we modularize dependencies? In other words, create components that do not depend words, create components that do not depend on one another?on one another? Maybe dependencies can be constructed at runtimeMaybe dependencies can be constructed at runtime Components have contractsComponents have contracts

8585

Build a DLS and GeneratorsBuild a DLS and Generators

Create a language that expresses the program Create a language that expresses the program behavior and that incorporates the idea of behavior and that incorporates the idea of extensibility on itextensibility on it LISP program with rules that are easily extensibleLISP program with rules that are easily extensible DSL with <extends> <plugs> <unplugs>DSL with <extends> <plugs> <unplugs> Generate code from it using modern techniquesGenerate code from it using modern techniques

Parnas’ approachParnas’ approachSoftware FamiliesSoftware FamiliesFlexibilityFlexibilityApproach to design flexible softwareApproach to design flexible software

8787

Parnas’ Criteria of DecompositionParnas’ Criteria of Decomposition

Information Hiding PrincipleInformation Hiding Principle The criteria involves variability and commonality The criteria involves variability and commonality

determinationdetermination “ “ We have tried to demonstrate by these examples that it is We have tried to demonstrate by these examples that it is

almost always incorrect to begin the decomposition of a system almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules cases, design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an will not correspond to steps in the processing. To achieve an efficient implementation we must abandon the assumption that a efficient implementation we must abandon the assumption that a module is one or more subroutines, and instead allow module is one or more subroutines, and instead allow subroutines and programs to be assembled collections of code subroutines and programs to be assembled collections of code from various modules.from various modules. ““

8888

Parnas’ Software Family MotivationParnas’ Software Family Motivation

According to Parnas [Parnas 78], software change is usually driven According to Parnas [Parnas 78], software change is usually driven by the need to support:by the need to support:

(1) Extensions motivated by social, organizational or (1) Extensions motivated by social, organizational or technological technological evolutionevolution;;

(2) New and different (2) New and different hardware configurationshardware configurations;; (3) Differences in its (3) Differences in its input and output datainput and output data, while its function is , while its function is

preserved;preserved; (4) Different data structures and implementations due to differences in (4) Different data structures and implementations due to differences in

the available the available resourcesresources;; (5) Differences in the (5) Differences in the size of datasize of data input and output; input and output; (6) And the need of some users of only a (6) And the need of some users of only a subset of featuressubset of features provided provided

by the software.by the software.

SolutionSolution: design software as a product family instead of a single : design software as a product family instead of a single product [Parnas 76].product [Parnas 76].

8989

Factors that hinder software evolutionFactors that hinder software evolution

Main factors that hider the program flexibility, Main factors that hider the program flexibility, according to Parnas [Parnas’76]:according to Parnas [Parnas’76]:

Excessive information distributionExcessive information distribution Programs are written assuming the presence or absence of Programs are written assuming the presence or absence of

a feature.a feature. Chain of data transforming componentsChain of data transforming components

Incompatible inputs and outputs are commonIncompatible inputs and outputs are common Originating order dependencies between componentsOriginating order dependencies between components

Components that perform more than one functionComponents that perform more than one function Loops in the “uses” relationLoops in the “uses” relation

Circular dependencies: programs are ready only when all Circular dependencies: programs are ready only when all components are readycomponents are ready

9090

Parnas’ generality principlesParnas’ generality principles According to [Parnas’78]According to [Parnas’78]

Generality as seen by mathematicians:Generality as seen by mathematicians: Solutions applicable without change to many situationsSolutions applicable without change to many situations

Generality as seen by engineersGenerality as seen by engineers A solution/product that can be tailored to the situation at handA solution/product that can be tailored to the situation at hand Efficiency and fitness to the problem are requiredEfficiency and fitness to the problem are required

Generality comes with runtime costsGenerality comes with runtime costs Flexibility supposes efficiencyFlexibility supposes efficiency

Parnas proposes the principles ofParnas proposes the principles of Anticipation of changeAnticipation of change: identify the main feature variability first: identify the main feature variability first

CommonalitiesCommonalities: minimal subset: minimal subset VariabilityVariability: minimal increments: minimal increments

Information hidingInformation hiding: hide the variability behind fixed interfaces: hide the variability behind fixed interfaces Lose couplingLose coupling: hide information about components from one another: hide information about components from one another Abstract data typesAbstract data types: hide implementation and structure details: hide implementation and structure details

Separation of concernsSeparation of concerns: modularization and specialization: modularization and specialization Virtual machine approach instead of transformation flowVirtual machine approach instead of transformation flow

9191

Parnas’ virtual machine approachParnas’ virtual machine approach

Parnas’ Virtual machine approach (domain engineering)Parnas’ Virtual machine approach (domain engineering) Virtual machine that has instructions operating over a set of small data typesVirtual machine that has instructions operating over a set of small data types System is designed as a subset of programsSystem is designed as a subset of programs Users customize the software by programming over or invoking existing subset Users customize the software by programming over or invoking existing subset Or writing incremental implementation of new instructions or data typesOr writing incremental implementation of new instructions or data types

The virtual approach must be constrained such that the “uses” hierarchy has The virtual approach must be constrained such that the “uses” hierarchy has no loops.no loops.

Layered architecture: The program is built according to different abstraction Layered architecture: The program is built according to different abstraction levelslevels

““Sandwitching”: When a circular dependency is unavoidable, a program Sandwitching”: When a circular dependency is unavoidable, a program must be split in two or more subprograms achieving a tree-like structure must be split in two or more subprograms achieving a tree-like structure

refactoring does pretty much thisrefactoring does pretty much this

Different from a kernel approach, where changes in the kernel impact the Different from a kernel approach, where changes in the kernel impact the whole system.whole system.

9292

AOP, Adaptive Programming and AOP, Adaptive Programming and Aspectual ComponentsAspectual Components

Those three technologies may help in Those three technologies may help in modularizing dependencies.modularizing dependencies.

According to D. Batory, the criteria to be used is According to D. Batory, the criteria to be used is stepwise refinement, using mixins and types as stepwise refinement, using mixins and types as parameters (constrained parametric parameters (constrained parametric polymorphism) added in layers – see Java polymorphism) added in layers – see Java Layers.Layers. One component = one feature, and has One component = one feature, and has

implementation for different classesimplementation for different classes

9393

Little experiment designLittle experiment design Build a simple pub/sub using OOBuild a simple pub/sub using OO Build using AOPBuild using AOP Build using Mixings (parameterized classes)Build using Mixings (parameterized classes) Build using design patternsBuild using design patterns

Understand the role of coupling and the flexibility Understand the role of coupling and the flexibility achieved in each approachachieved in each approach

Characterize the kinds of dependencies, especially event Characterize the kinds of dependencies, especially event routing routing subscription subscription

Finally build a “criteria”, in the form of a catalog of Finally build a “criteria”, in the form of a catalog of dependencies dependencies realization techniques realization techniques

This may lead to better understanding and This may lead to better understanding and generalizationsgeneralizations

9494

QuotesQuotes

““CORBA's numerous technical flaws have accumulated CORBA's numerous technical flaws have accumulated to a point where it is difficult to fix or add anything to a point where it is difficult to fix or add anything without breaking something else. For example, every without breaking something else. For example, every revision of CORBA's interoperability protocol had to revision of CORBA's interoperability protocol had to make incompatible changes, and many fixes and make incompatible changes, and many fixes and clarifications had to be reworked several times because clarifications had to be reworked several times because of unforeseen interactions with features that were added of unforeseen interactions with features that were added over time. “. over time. “. ACM Queue vol. 4, no. 5 - June 2006 bACM Queue vol. 4, no. 5 - June 2006 by y Michi Henning, ZeroCMichi Henning, ZeroC

9595

Managing dependenciesManaging dependencies Build a feature dependency modelBuild a feature dependency model

Early identification is a key thingEarly identification is a key thing Characterize the dependenciesCharacterize the dependencies

Identify fundamental (common) and feature-specific dependenciesIdentify fundamental (common) and feature-specific dependencies

Find transition paths between dependencies, for example:Find transition paths between dependencies, for example: Filtering Filtering event event Filtering Filtering timing timing Timing Timing Routing Routing event event Routing Routing content operator content operator ……

Apply the modularization criteria based on the nature of the Apply the modularization criteria based on the nature of the dependency:dependency: Separation of concerns Separation of concerns

Using information hiding (OO), aspect-oriented programming (AOP), mixins, Using information hiding (OO), aspect-oriented programming (AOP), mixins, others.others.

Information and Computer Science

that's the missing leap, what is the criteria, how to go from dependencies to the right set of techniques?

9696

ReferencesReferences Bosch, J., G. Florijn, et al. Bosch, J., G. Florijn, et al. (2001). (2001). Variability Issues in Software Product LinesVariability Issues in Software Product Lines. 4th . 4th

International Workshop on Software Product Family Engineering - PFE'2002, Bilbao, International Workshop on Software Product Family Engineering - PFE'2002, Bilbao, Spain, Publisher: Springer Berlin / Heidelberg.Spain, Publisher: Springer Berlin / Heidelberg.

Bosh, J. (2000). Bosh, J. (2000). Design & Use of Software Architectures - Adopting and Evolving a Design & Use of Software Architectures - Adopting and Evolving a Product Line ApproachProduct Line Approach, Addison-Wesley., Addison-Wesley.

Coplien, J., D. Hoffman, et al. Coplien, J., D. Hoffman, et al. (1998). Commonality and Variability in Software (1998). Commonality and Variability in Software Engineering. Engineering. IEEE SoftwareIEEE Software. . 15: 15: 37-45.37-45.

Griss, M. L. (2000). Griss, M. L. (2000). Implementing Product-Line Features with Component ReuseImplementing Product-Line Features with Component Reuse. 6th . 6th International Conference on Software Reuse, Vienna, Austria.International Conference on Software Reuse, Vienna, Austria.

Kang, K. C. (1998). "FORM: A Feature-Oriented Reuse Method with Domain Specific Kang, K. C. (1998). "FORM: A Feature-Oriented Reuse Method with Domain Specific Architectures." Architectures." Annals of Software EngineeringAnnals of Software Engineering 55: 345-355.: 345-355.

Kang, K. C., S. G. Cohen, et al. (1990). Feature-Oriented Domain Analysis (FODA) Kang, K. C., S. G. Cohen, et al. (1990). Feature-Oriented Domain Analysis (FODA) Feasibility Study - CMU/SEI-90-TR-021. Pittsburgh, PA, Carnegie Mellon Software Feasibility Study - CMU/SEI-90-TR-021. Pittsburgh, PA, Carnegie Mellon Software Engineering Institute.Engineering Institute.

Kiczales, G., J. Lamping, et al. (1997). Kiczales, G., J. Lamping, et al. (1997). Aspect-Oriented ProgrammingAspect-Oriented Programming. European . European Conference on Object-Oriented Programming, Jyväskylä, Finland, Springer-Verlag.Conference on Object-Oriented Programming, Jyväskylä, Finland, Springer-Verlag.

Lientz, B. P. and E. B. Swanson (1980). Lientz, B. P. and E. B. Swanson (1980). Software Maintenance Management: A Software Maintenance Management: A Study of the Maintenance of Computer Application Software in 487 Data Processing Study of the Maintenance of Computer Application Software in 487 Data Processing Organizations (Ch. 27)Organizations (Ch. 27). Rading, MA, Addison-Wesley.. Rading, MA, Addison-Wesley.

S. M. McMenamin and J. Palmer, Essential Systems Analysis. Englewood Cliffs, NJ: S. M. McMenamin and J. Palmer, Essential Systems Analysis. Englewood Cliffs, NJ: Yourdon Press Prentice Hall, 1984.Yourdon Press Prentice Hall, 1984.

9797

References (cont)References (cont) Mezini, M. and K. Lieberherr (1998). Mezini, M. and K. Lieberherr (1998). Adaptive plug-and-play components for evolutionary Adaptive plug-and-play components for evolutionary

software developmentsoftware development. 13th ACM SIGPLAN conference on Object-oriented programming, . 13th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, Vancouver, British Columbia, Canada, ACM Press.systems, languages, and applications, Vancouver, British Columbia, Canada, ACM Press.

Ommering, R. v., F. v. d. Linden, et al. (2000). The Koala Component Model for Consumer Ommering, R. v., F. v. d. Linden, et al. (2000). The Koala Component Model for Consumer Electronics Software. Electronics Software. IEEE ComputerIEEE Computer. . 33: 33: 78-85.78-85.

Parnas, D. L. (1972). On the Criteria to Be Used in Decomposing Systems into Modules. Parnas, D. L. (1972). On the Criteria to Be Used in Decomposing Systems into Modules. Communications of the ACMCommunications of the ACM. . 15: 15: 1053-1058.1053-1058.

Parnas, D. L. (1976). "On the Design and Development of Program Families." IEEE Transactions Parnas, D. L. (1976). "On the Design and Development of Program Families." IEEE Transactions on Software Engineering SE-2(1): 1-9.on Software Engineering SE-2(1): 1-9.

Parnas, D. L. (1978). Parnas, D. L. (1978). Designing software for ease of extension and contractionDesigning software for ease of extension and contraction. 3rd international . 3rd international conference on Software engineering, Atlanta, Georgia, USA, IEEE Press.conference on Software engineering, Atlanta, Georgia, USA, IEEE Press.

Sommerville, I. (2001). Sommerville, I. (2001). Software Engineering (6th Edition)Software Engineering (6th Edition).. Svahnberg, M., J. v. Gurp, et al. Svahnberg, M., J. v. Gurp, et al. (2005). "A Taxonomy of Variability Realization Techniques." (2005). "A Taxonomy of Variability Realization Techniques."

Software Practice and ExperienceSoftware Practice and Experience 3535(8): 705-754.(8): 705-754. Trigaux, J. C. and P. Heymans (2003). Modelling variability requirements in Software Product Trigaux, J. C. and P. Heymans (2003). Modelling variability requirements in Software Product

Lines: A comparative survey. Namur, Belgium, Institut d’Informatique FUNDP.Lines: A comparative survey. Namur, Belgium, Institut d’Informatique FUNDP. van Gurp, J., J. Bosch, et al. (2001). van Gurp, J., J. Bosch, et al. (2001). On the notion of variability in software product linesOn the notion of variability in software product lines. .

Working IEEE/IFIP Conference on Software Architecture - WICSA'2001, Amsterdam, IEEE.Working IEEE/IFIP Conference on Software Architecture - WICSA'2001, Amsterdam, IEEE. Karl Lieberherr. Adaptive Object-Oriented Software: The Demeter Method with Propagation Karl Lieberherr. Adaptive Object-Oriented Software: The Demeter Method with Propagation

Patterns, PWS Publishing Company, ISBN: 0-534-94602-X, 1996. Patterns, PWS Publishing Company, ISBN: 0-534-94602-X, 1996. R. M. Pratap, F. Hunleth, and R. K. Cytron, "Building fully customisable middleware using an R. M. Pratap, F. Hunleth, and R. K. Cytron, "Building fully customisable middleware using an

aspect-oriented approach," IEE Proceedings - Software Engineering, vol. 151, pp. 199-216, aspect-oriented approach," IEE Proceedings - Software Engineering, vol. 151, pp. 199-216, 2004.2004.

9898

References (cont)References (cont) Wilde, N., P. Matthews, et al. (1993). "Maintaining object-oriented software." Wilde, N., P. Matthews, et al. (1993). "Maintaining object-oriented software." IEEE IEEE

Software 10(1): 75-80.Software 10(1): 75-80. McIlroy, M. D. (1968). McIlroy, M. D. (1968). Mass Produced Software ComponentsMass Produced Software Components. In Software Engineering: A . In Software Engineering: A

Report on a Conference Sponsored by the NATO Science Committee. P. Naur and B. Report on a Conference Sponsored by the NATO Science Committee. P. Naur and B. Randell (eds.), Garmisch, Germany.Randell (eds.), Garmisch, Germany.

Brooks, F. P. (1987). No Silver Bullet: Essence and Accident in Software Engineering. Brooks, F. P. (1987). No Silver Bullet: Essence and Accident in Software Engineering. IEEE Computer 20IEEE Computer 20. . 10: 10: 10-19.10-19.

Cameron, E. J. and H. Velthuijsen (1993). "Feature interactions in telecommunications Cameron, E. J. and H. Velthuijsen (1993). "Feature interactions in telecommunications systems." systems." IEEE Communications MagazineIEEE Communications Magazine 3131(8): 18-23.(8): 18-23.

Lee, K. and Kang, K.C. Feature Dependency Analysis for Product Line Component Lee, K. and Kang, K.C. Feature Dependency Analysis for Product Line Component Design. Lecture Notes in Computer Science - 8th International Conference on Software Design. Lecture Notes in Computer Science - 8th International Conference on Software Reuse, ICSR'04, 3107. 69-85.Reuse, ICSR'04, 3107. 69-85.

Hunleth, F. and Cytron, R.K., Footprint and feature management using aspect-oriented Hunleth, F. and Cytron, R.K., Footprint and feature management using aspect-oriented programming techniques. in Joint conference on Languages, compilers and tools for programming techniques. in Joint conference on Languages, compilers and tools for embedded systems: software and compilers for embedded systems, (Berlin, Germany, embedded systems: software and compilers for embedded systems, (Berlin, Germany, 2002), ACM Press, 38 - 45.2002), ACM Press, 38 - 45.

Sanchez, C., Sankaranarayanan, S., Sipma, H., Zhang, T., Dill, D. and Manna, Z. Event Sanchez, C., Sankaranarayanan, S., Sipma, H., Zhang, T., Dill, D. and Manna, Z. Event Correlation: Language and Semantics. Embedded Software (EMSOFT), LNCS 2855. Correlation: Language and Semantics. Embedded Software (EMSOFT), LNCS 2855. 323-339, 2003.323-339, 2003.

Zhang, C. and Jacobsen, H.-A., Resolving feature convolution in middleware systems. in Zhang, C. and Jacobsen, H.-A., Resolving feature convolution in middleware systems. in 19th annual ACM SIGPLAN Conference on Object-oriented programming, systems, 19th annual ACM SIGPLAN Conference on Object-oriented programming, systems, languages, and applications, (Vancouver, BC, Canada, 2004), ACM, 188-205.languages, and applications, (Vancouver, BC, Canada, 2004), ACM, 188-205.

9999

References (cont)References (cont)

Backup slidesBackup slides

101101

Runtime bindingRuntime binding There is a need for reflection: location of the There is a need for reflection: location of the

other components that implement the featureother components that implement the feature

Build time bindingBuild time binding Dependencies can be resolved by the Dependencies can be resolved by the

compilercompiler

Feature internal dependencies - Feature internal dependencies - consequencesconsequences

102102

Software Variability AnalysisSoftware Variability Analysis

Scope Commonality Variability (SCV) modelScope Commonality Variability (SCV) model Main Steps:Main Steps:

1.1. Establish the scopeEstablish the scope2.2. Identify the commonalities and variabilityIdentify the commonalities and variability3.3. Bound the variability by applying limits to themBound the variability by applying limits to them4.4. Exploit the commonalitiesExploit the commonalities5.5. Accommodate the variabilityAccommodate the variability

Existing methodologiesExisting methodologies SCV, FODA, FORMSCV, FODA, FORM

software engineering and product-line architectures: problem domain roberto silveira silva filho...

Documents

software evolution

software domain

software featuresmotivation

kind software

software developmentsoftware

software easier

software product line

opportunistic software