Upload
lesley-fowler
View
213
Download
0
Tags:
Embed Size (px)
Citation preview
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
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
Common (mandatory) features
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
Common (mandatory) features
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
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>>
<<optional>> == OR<<optional>> == OR <<mandatory>> == AND<<mandatory>> == AND <<exclusive>> == XOR<<exclusive>> == XOR
4747
Feature Diagram (zoom right)Feature Diagram (zoom right)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>>
<<optional>> == OR<<optional>> == OR <<mandatory>> == AND<<mandatory>> == AND <<exclusive>> == XOR<<exclusive>> == XOR
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>>
Sequence operator<<optional>>
Filtering<<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.
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.
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