r2pl, pittsburgh november 10, 2005 copyright © fraunhofer iese 2005 identifying domain-specific...

R2PL, PittsburghNovember 10, 2005

Copyright © Fraunhofer IESE 2005

Identifying Domain-Specific Reusable

Components from Existing OO Systems to

Support Product Line Migration

Dharmalingam [email protected]

Jens [email protected]



Identifying Domain-Specific Reusable Components from Existing OO Systems to Support Product Line Migration

Motivation

• Challenges for software-developing organizations today

- Need for reducing cost, effort, and time-to-market

- Complexity and software size increases

- Increasing request for quality software and individually customized products

• Reuse is a promising solution

- Reusing existing software saves time and effort

- Reusing approved software brings quality

- Focusing on new functionality enables realization of individual requirements

• Software product lines stand for pro-active, strategic, and successful reuse




Motivation …

• Most organizations already invested effort in developing single systems

- We can not ignore the existing software and start a product line from scratch

• Systems consist of- Domain-specific components 65% - Application-specific components 15%- Utility components 20%

[Poulin 1997]

• Goal: - Identification of domain-specific components- Most-relevant for a product line

Large degree of commonality Investment into reuse pays off




Idea: Component Extraction

Define ReusabilityModel

Reusability Model

Apply the model

Component candidates

ComponentRepository

Select useful components

Existing system

Update model

fact base

Extract facts




Factors Affecting Reusability

Reusability

Usefulness

QualityCosts

Processing ControlWithina system Overall

Withina domain

Variety offunctions

TransferCommonalityof function

PackagingIdentification

Qualification

Extraction Retrieval

Modification

Integration

Use in newsystems

Ease ofmodification

Correctness

Testability

Readability

Performance

TimeSpace

Reusability

Usefulness

QualityCosts

Processing ControlWithina system Overall

Withina domain

Variety offunctions

TransferCommonalityof function

PackagingIdentification

Qualification

Extraction Retrieval

Modification

Integration

Use in newsystems

Ease ofmodification

Correctness

Testability

Readability

Performance

TimeSpace




Metrics Affecting Reusability

• Use existing validated OO metrics to measure quality, cost, and usefulness

• Automatic computation of metrics

[Chidamber 1994]

Metric DefinitionNMPUB The number of public methods implemented by a class.WMC Cyclomatic complexity of a class.NOC The number of children/grandchildren of a class.DIT The level a class is located from the root in the inheritance hierarchyOCAEC The number of times a class has been used as an attribute in other classes.CALLS_IN The total number of times the methods of a class was called by other classes.LCOM Cohesion - The number of sets of methods that access the same attributes




Mapping Metrics to Factors

Reusability

Usefulness

Quality

Costs

Variety offunctionsCommonality

of function

LCOMWMC

CALL_IN

CALL_USAGEOCAECNOC DIT

NMPUB

WMC

NMPUB

WMC

LCOM




Defining Reusability Model

Metric Minimum Maximum

NMPUB X X

WMC X X

LCOM X

DIT X

NOC X

CALL_IN X

OCAEC X




Approach

1. Goal Description

2. Setting up the fact base

3. Select metrics and choose its bounds

4. Identify candidates (classes)

5. Lightweight review by the reverse engineer

6. Review by the domain expert• Assign type of classes (domain, application,

utility)

7. Analyze classification- Filtering strategy- Selection strategy

8. Component building

9. Interface Analysis

10.Final decision and integration




Case Study (1)

• Development of a family of IDEs (Integrated Develop Environment) for modeling product line architectures as an Eclipse Plug-in

- Identify, extract, and reuse (and adapt) components from existing IDEs

Java Development Tools (JDT) C/C++ Development Tool (CDT)

- Examples: Project management Workspace management Editor functionality




Case Study (2)

• First iteration- Subject Eclipse JDT

org.eclipse.jdt.internal.core

- Metrics boundaries Average metric value to define the reusability

model

- Computation of class candidates Review by expert

- Expert review and assignment Domain-Specific: Classes that can be reused in

more than one project in the given domain Application-Specific: Classes specific to a given

application Mixture: Implementation is a mixture of Domain-

specific and Application-specific Other: Unclear




Case Study (3)

Distribution of Reviewed Candidates

Domain_Specific43%

unclear15%

Mixture15%

Appli_Specific27%

Domain_Specific

Appli_Specific

unclear

Mixture




Conclusion

• Achievements so far

- Identification of domain-specific classes

- First set of useful metrics

• Ongoing work

- Case study with Eclipse

- Construction of components based on domain-specific classes

- Derivation on default boundaries for metrics




Points for Discussion

• How to define a reusability model ?

- How to choose bounds for metrics

• What other metrics are indicators for domain-specific classes?

• How to construct the domain-specific components from the identified classes ?

• How to keep manual effort for candidate review limited ?

• How to minimize the number of iterations for identifying the domain-specific components ?

r2pl, pittsburgh november 10, 2005 copyright © fraunhofer iese 2005 identifying domain-specific...

Documents