A reuse environment was defined by [Frakes, 1994] as an environment where process and tools give support for activities that are important to build components with/for reuse. According to [Griss, 1994], a repository is one of the most important elements in a reuse environment. However, the quality of the assets on the repository had been questionable according to the type of reuse model adopted.
We are thinking about a reuse model where anyone can store assets on the repository without previous analysis. In this model, we have a low reliability about the reusable assets because anyone can store assets and who will reuse don’t have assets' quality assurance. In this model, the main problems are low reliability and a concern about code problems propagation.
We are developing an approach that can minimize these problems. In this approach, the repository can check the stored assets' quality according to metrics. For this initial stage, we are considering a repository where are stored only Java code. Thus, to develop this approach we accomplish the main steps: (i) investigate code metrics that can be used; (ii) select quality attributes; and (iii) quality attributes measurement.
In the first step, we made a time line about software code metrics and selected a set of metrics that can be used in our approach. We analyzed ten metrics groups and we were selecting the metrics according the following criteria: applicable for Java code; there are researche reporting about empiric validation; there are a consistent theoretical validation; and the metrics have a good acceptance, in other words, they were implemented in the analyzed metrics tools. The selected metrics were LOC, Cyclomatic Complexity [McCabe, 1976] and Chindamber and Kemerer metrics [Chidamber, 1994].
The second step was to select what type of quality attributes would be quantified in our approach. We selected the Maintainability quality attribute described in ISO 9126. In the third step, we made a relationship between each quality attribute of Maintainability and a set of metrics selected that can quantify these attributes. So, this approach can quantify a set of quality attributes using code metrics.
We are thinking about a reuse model where anyone can store assets on the repository without previous analysis. In this model, we have a low reliability about the reusable assets because anyone can store assets and who will reuse don’t have assets' quality assurance. In this model, the main problems are low reliability and a concern about code problems propagation.
We are developing an approach that can minimize these problems. In this approach, the repository can check the stored assets' quality according to metrics. For this initial stage, we are considering a repository where are stored only Java code. Thus, to develop this approach we accomplish the main steps: (i) investigate code metrics that can be used; (ii) select quality attributes; and (iii) quality attributes measurement.
In the first step, we made a time line about software code metrics and selected a set of metrics that can be used in our approach. We analyzed ten metrics groups and we were selecting the metrics according the following criteria: applicable for Java code; there are researche reporting about empiric validation; there are a consistent theoretical validation; and the metrics have a good acceptance, in other words, they were implemented in the analyzed metrics tools. The selected metrics were LOC, Cyclomatic Complexity [McCabe, 1976] and Chindamber and Kemerer metrics [Chidamber, 1994].
The second step was to select what type of quality attributes would be quantified in our approach. We selected the Maintainability quality attribute described in ISO 9126. In the third step, we made a relationship between each quality attribute of Maintainability and a set of metrics selected that can quantify these attributes. So, this approach can quantify a set of quality attributes using code metrics.
The next stage in this work is to integrate the approach automation in a reuse environment. Thus, we want to analyze if the retrieved component's quality is better, and if it is possible this approach to reduce the reuse of low quality code. We believe the main contribution of this research is to introduce a little bit of the quality analysis responsibility of the reusable assets also to the repository. Thus, we can have more reliability in a reuse environment without a certification process for stored assets on the repository, moreover it can reduce the cost to introduce reuse in a begging stage.
1 comment:
I have some points about your post. First of all, I think that it can be good to understand what are the users’ expectations looking for a component or peace of code: just to learn about it (piece of code) or reuse it with/without modification. Because, if is just to learn, they do not care about the quality, right?
About the approach, I have some points: i. how can you assure that these metrics can be good to measure your goals? I am not sure about LOC and your goals. Actually, I would like to see a GQM approach about it. With your goal and derived metrics.
Why did you choose maintainability? What were the criteria to choose it and do not consider the others one?
Post a Comment