A SURVEY ON OBJECT-ORIENTED DESIGN IMPROVEMENT

Transcription

1 IADIS International Conference e-society 2006 A SURVEY ON OBJECT-ORIENTED DESIGN IMPROVEMENT Juan José Olmedilla Arregui Almira Labs, S.L., Paseo Pintor Rosales 76, 28008, Madrid, Spain ABSTRACT Since (Chidamber and Kemerer, 1991) many Object-Oriented (OO) metrics suites have been proposed claiming to be focused on measuring software design, as opposed to measuring the products of software development, such as code or other products of the software lifecycle. The metrics for these suites are not focused on productivity but rather on design quality; they try to evaluate, in a quantitative way, if certain targets such as encapsulation, cohesion, abstraction and coupling, supposedly desirable for OO design, are being met. However, since the birth of concepts such as design patterns (Gamma et al., 1995) and refactoring (Fowler, 2000) new elements have been added to the OO literature to aid with the evaluation of design. So how can we evaluate the quality of a design? Is there a set of accepted internal attributes to measure it? Furthermore, if such a set exists, will it be possible to find metrics that can guide a Software Design Improvement (SDI) method, in the same way that Software Process Improvement models (Paulk et al., 1993, Humphrey, 1989) are guided by process metrics? KEYWORDS Object oriented design, software quality, software metrics, systematic review. 1. INTRODUCTION Some aspects of software products have been measured almost since the beginning of computing history, such as size, complexity, defect arrival rate, and test coverage; so have aspects of the software development process, such as productivity. The objectives targeted by these measurements may be a method for development effort estimation, calculation of test coverage in quality assurance or the evaluation of the software process maturity level in an organization. It is precisely this growing interest for the software process improvement (Humphrey, 1989) that has helped in the adoption of software metrics. Software process improvement (SPI) helps organizations in two ways: first by identifying all the broad areas of the process, i.e. the goals, activities and sub-activities needed to achieve it; then by establishing a path through which the process can be incrementally improved. This path is a set of quality levels, each of them divided in areas and their associated goals to be accomplished. Fundamental to the SPI are the metrics, which are the tools by which the organization can measure its progress along the improvement path. Each of the aforementioned goals has an associated set of metrics that help determine if it has been achieved, and to what extent. Just like with software processes, a method or model for the improvement of the quality of the software product can be established. Process areas could be replaced by product characteristics, and a set of quality levels could be defined, as well as metrics, to measure them. The quality levels need not be incremental; instead they could be horizontal, for example, by using application domains (real time, scientific computing, human interaction centered, etc) as target levels. Thus an organization could choose the target level that best suits its needs. A fundamental question that managers and developers often face is whether it is worth improving a software product by re-engineering it, or whether it is better to simply start over from scratch. Fowler (2000) states that: There are times when the existing code is such a mess that although you could refactor it, it would be easier to start from the beginning. [ ] I admit that I don t really have good guidelines for it (p. 66). 517

2 ISBN: X 2006 IADIS There is plenty of knowledge in the literature (Brown et al., 1998, Fowler, 2000, Gamma et al., 1995) about how to identify situations in which to apply specific design improvements, but, is there a formal method to know which transformations should be applied first? We are talking here about something that we could call an OO Design Maturity Model that would help designers to assess and improve a design before having to implement it This chapter will review the state of the art to see whether there is an accepted set of internal quality properties as high level indicators or goals for the assessment of OO micro architecture design quality and if there are already assessment models that map metrics, OO properties and these high level indicators. A secondary objective of the review is to identify which role the OO knowledge elements play in the assessment. There might be evaluation models based on the detection of these elements in the design, so that they will not only be part of the improvement model, but also of the appraisal. The sources of review will be journals, transactions, conference proceedings and other periodicals published in the main areas of knowledge affected by this study: Object Orientation Design, Metrics and Software Maintenance. In section 2 a background on software product quality and OO metrics and OO knowledge will be presented, in section 3 the method followed to perform the review will be explained and the results exposed along with critical comments on the most relevant studies, and conclusions will be drawn in section BACKGROUND First we must define the context of this paper, since software quality has two possible interpretations: one is process quality, and product quality. We are clearly focused on software product quality, and within it, we will focus on the product resulting from the design phase (2004). The only standard we have found in the literature which defines software product quality using attributes is ISO 9126 (ISO/IEC, 2001). This standard states that software product quality can be evaluated by measuring internal attributes, or by measuring external attributes; the former are obtained through metrics defined on intermediate products, such as design, and the latter are based on the behaviour of the final executing code. It also takes into account quality in use which deals with the perspective of behavioural quality of the finished product in a specific environment under a user s perspective. In both cases, internal and external, quality is defined as a set of 6 characteristics: functionality, reliability, usability, efficiency, maintainability and portability. These characteristics are general for any kind of software product and being Object-Oriented or structured does not affect the choice of characteristics, although it will affect the way to measure them. They are further sub-divided into sub-characteristics. Performance, availability (or reliability) and modifiability (changeability as sub-characteristic of maintainability in ISO 9126) appear in the literature as the three main quality attributes used in Software Architecture evaluation methods and in our study they have been taken into account, however we are not interested here in macro-architecture evaluation and therefore we are not looking at the characterization of them in the same sense as (Clements et al., 2002). The object of our study is OO micro architecture design in which some technological and environmental aspects of that characterization have no impact, as for example detection of hardware failures, scheduling techniques, latency, etc. The software architecture quality attributes can help to decide which internal quality attributes are target to be maximized in an eventual Software Design Improvement method, but they are by themselves regarded as external attributes as micro architecture is concerned. The ISO 9126 standard tries to establish a general definition of software product quality, from user s perspective as from the developer s perspective, hence the existence of the external and internal perspectives. However there exist intermediate sub-products on which quality measures can be performed before the product completion, and therefore they are a basis for quality predictions of the finished product. Bansiya and Davis (2002) use a set of six design quality attributes, which have been adapted from ISO 9126 quality characteristics; the change was deemed necessary in order to adapt to the demands of measuring design quality. Two attributes were discarded as not measurable in design, two were changed for equivalent ones, and two were added which stemmed from general concepts present in software design literature. Until now we have referred to general software design quality attributes; but we have not narrowed down our attributes for OO design, nor have we talked about how to measure them. We must find properties of the object of study, design in our case, that are directly observable and measurable; also we must establish if 518

3 IADIS International Conference e-society 2006 there is a known relationship between these properties and the chosen metrics. In many of the OO metrics suites, the specific metrics are implicitly mapped to general design properties as cohesion, coupling, encapsulation, complexity and inheritance, although not all of them are specific of OO design and could be applied to modular design as well. Measurements are proposed in different works for those properties, and in some cases, there is an explicit mapping from the former to the latter, like in (Bansiya and Davis, 2002) where each design property is measured by a single metric. In (Miller et al., 1999) 11 object-oriented design principles, which, according to Garzás and Piattini (2005) are part of the OO architecture knowledge, are chosen as properties; and 5 measurements, all of them at class level, are used to assess their degree of fulfillment. On the contrary Bansiya and Davis (2002) choose not only classes but also class attributes, methods and packages. An incomplete but significant list of OO design properties could be: Design size, Hierarchies, Abstraction, Encapsulation, Coupling, Cohesion, Composition, Inheritance, Polymorphism, Messaging and Complexity. But these quality attributes and OO design properties must be measured on specific components or entities of the design, thus it is important to define what a design is or what components of a design can be measured. Purao and Vaishnavi (2003) survey product metrics for OO systems and propose a framework by which the product goes through different states during the development process; and in each of these states, different components, that they call entities, are produced or modified. In their work, Purao and Vaishnavi review all the different metrics suites to see what entities are measured in each state, and gather an extensive set which can be summarized in the following list: association, attribute, class, hierarchy, link, method, package, parameter, scenario, system and use case. Once we know what we want to obtain, the measurements of a set quality properties and the entities on which to perform them, we must define a set of adequate metrics. Currently there are many OO metrics suites as we can see in (Purao and Vaishnavi, 2003, Briand et al., 2000) although most of them cannot be applied directly to design entities, since they need the source code to be measured. Also, the different OO metrics suites are focused on a very limited set of OO properties, mainly, coupling, cohesion and inheritance; these are also applicable to structured programming and/or design. S.R. Chidamber and C.F. Kemerer (C&K) were the first ones (1991) to establish a set of six product metrics specifically for OO code; all but one are applied to classes and try to measure complexity, coupling, cohesion, inheritance and messaging. From C&K initial suite different modifications and additions have been proposed: for example, Li and Henry s suite (1993) introduces modifications to some metrics and add four new ones. This new suite is focused on the measurement and improvement of OO software maintainability, for which abstraction and design size are added as target properties. Henderson-Sellers, Constantine and Graham (1996) offered their own suite, which is mostly centered on coupling and cohesion. Table 1. Bansiya and Davis metrics Metric Definition Properties Design size of classes (DSC) Total number of classes in the design Design size Number of Hierarchies Number of classes Hierarchies (NOH) Average number of ancestors Average Number of ancestors Abstraction (ANA) Data access Metric (DAM) Ratio of the number of private (protected) attributes to the Encapsulation total number of attributes declared in the class Direct class coupling (DCC) Count of different number of classes that a class is directly Coupling related to. The metric includes classes that are directly related by attribute declarations and message passing (parameters) in methods Cohesion among methods of class (CAM) This metric computes the relatedness methods of a class based upon the parameter list of the methods. The metric is computed using the summation of the intersection of parameters of a method with the maximum independent set of all parameter types in the class. Cohesion Measure of aggregation (MOA) This metric measures the extent of the part-whole relationship, realized by using attributes. The metric is a count of Composition 519

4 ISBN: X 2006 IADIS Measure of functional abstraction (MFA) Number of polymorphic methods (NPM) the number of data declarations whose types are user defined classes. Ratio of the number of methods inherited by a class to the total number of methods accessible by member methods of the class Number of methods that can exhibit polymorphic behaviour (virtual in C++ and non final in Java) Inheritance Polymorphism Class interface size (CIS) Count of the number of public methods in a class Messaging Number of methods (NOM) Count of methods defined in a class. Complexity 3. METHOD AND RESULTS 3.1 Systematic Review Procedure A systematic review protocol following (Kitchenham, 2004) was used. In the following sections the protocol followed in this study is briefly summarized, although we do not show the full search queries for the sake of brevity. A custom database was designed to collect specific elements, such as the quality criteria, while doing the initial reading either the full papers or their abstracts. Those studies that fulfilled the basic selection criteria where saved in electronic format (PDF). MS Access was used for the database and BibTeX and EndNote for the bibliographic management. 3.2 Review Questions We are interested in those metrics that can be used to evaluate design quality based exclusively on design entities and that can be related to quality attributes such as those in ISO 9126; we want to know if there is any solid research that has established a set of OO properties and their relation with these quality attributes using OO design knowledge (patterns, heuristics, bad smells, best practices, rules and principles). We are constrained exclusively to the design phase and more specifically to OO micro architecture as in SWEBOK (Abran et al., 2004), which does not define it explicitly, but differentiates between micro and macro architecture patterns. Thus we will refer to objects and classes, their structure and relationship among them but not internal aspects of their methods, more related with implementation. The primary question of research is: Research Question 1: Are there Object Oriented design quality assessment models that use a set of metrics, based only in design entities, to measure levels of accomplishment in internal product quality attributes (as those in ISO 9126)? What are those attributes or high level indicators? The secondary question of research is: Research Question 2: Do those models use any of the OO knowledge elements in (Garzás and Piattini, 2005) as part of that assessment, and if so how? 3.3 Method The sources chosen were: IEEE Digital Library, ACM Digital Library, Journal of Systems and Software (Elsevier), Journal of Software Maintenance and Evolution (Wiley), Software Practice and Experience (Wiley) and Google Scholar (scholar.google.com), the latter only for publications within last year. Our search strategy was to compose queries that included in different Boolean expressions the following terms: Object Oriented design, Metrics, Quality, High level indicators, Assessment, Method, Patterns, Heuristics, Bad smells, Principles, Rules, Refactoring, Lessons learned, Best practices. Different queries were created with these terms and executed in the search engines; however some of them had to be expanded to obtain a decent set of results, like in the case of the Journal of Systems and Software given. Afterwards, the selection had to be manually reviewed to exclude publications that were completely out of the scope. 520

5 IADIS International Conference e-society 2006 Once duplicates were taken out, 572 studies remained. After obtaining this initial list of results, we did a quick review of either the abstract of each paper or of its introduction, when available, and directly discarded those not concerned with object-oriented metrics. After that initial review, we did a more thorough inspection by reading the publications one by one, and using the exclusion criteria explained in section 3.4 to discard those deemed irrelevant. The remaining studies, that is, the primary sources of our review, were assigned a type according to a set of quality assessment levels based on the experimental data they included. Since all studies were within the same range of experimental quality we decided not to use experimental quality as an exclusion criteria, and therefore accepted all studies that had arrived to this point. Table 2. Summary of collected data Number of studies Accepted studies Primary sources Total Accepted Discarded Primary Secondary Full models (use Use design exclusively Use also source sources sources code and design) code Exclusion Criteria The exclusion criteria used in the more thorough review were: Exclusion criterion 1: Study does not focus on metrics for design improvement, like those too general and including effort and quality assurance. Exclusion criterion 2: Study does not propose an assessment model with quality attributes as the target of the metrics. Given the low number of studies that passed the exclusion criteria we decided to record as well those studies that, not proposing a general assessment model were focused on prediction of one or two quality attributes, recording those attributes as well; the studies that passed all criteria were called primary sources and these latter were called secondary sources (see Table 2). 3.5 Data extraction We were interested in obtaining the high level indicators or internal quality attributes that could be utilized in a design improvement methodology, so we recorded all those indicators in the primary studies. For each of the studies a Boolean variable (Yes/No) was kept in the database, in order to record if the study was proposing a full quantified evaluation model from metrics to quality attributes going through the chosen OO properties. Although all primary studies proposed some OO design evaluation method, only four of them described a full quantified model, we have called them full models. We also recorded a variable to know if the study was applying the metrics to design entities, that is, to a design document or UML diagrams (any of them), or whether it was applying them to source code but certain extrapolation could be done to design. In the latter case, this would mean that even though source code was used in the particular study, metrics could still be calculated only with design entities instead, as for hierarchies or inheritance depth. In some case the variable was marked as false because, although most metrics could be measured on design, the study was doing it on source code and including at least one metric impossible to calculate over design entities, such as SIZE1 or LCOM. Table 3. Collected high level indicators Name Primary Studies using design exclusively Secondary sources Full Models Sources Adaptability Analysability Change proneness Changeability Completeness Complexity

6 ISBN: X 2006 IADIS Comprehensibility Consistency Correctness Effectiveness Efficiency Extensibility Flexibility Functionality Maintainability Performance Realisability Reliability Reusability Security Stability Testability Traceability Unambiguity Understandability Usability Verifiability In Table 2 a summary of the collected results can be seen. For each high-level indicator, we can see the number of primary sources, full models, sources whose method or metrics can be applied to design exclusively, number of primary sources that are also full models (two of them using design exclusively) and, finally, primary sources that need source code for their analysis. In Table 3 we show quality attributes that have been collected in primary sources, with the original names they have in the papers, in some cases we have simplified by assigning the same name as in other studies when the semantics are the same in order not to have too many different names; however there still is some redundancy like in the case of analysability, understandability and comprehensibility. It must be taken into account that all these attributes refer to design, and that, for instance, "understandability" means in this context that the design is easily understandable by a software developer other than its author, therefore it must not be taken as the sub-characteristic beneath "usability" in ISO Results From the results it can be concluded that less than a half of the studies that try to establish a way to evaluate the quality of an OO design are based on design entities; from 25 primary sources 14 are based on source code. From the data obtained in Table 3 we can conclude that, for the so called full models, maintainability, counting its sub-characteristics, was the highest scoring quality attribute with a total of 8 appearances. Maintainability is comprised of analysability, changeability, stability and testability, and, in this context, analysability, comprehensibility and understandability are synonyms, being semantically similar; and the same can be said about changeability, flexibility and extensibility. Another important attribute or high-level indicator is reusability. One finding is that, when trying to establish a quality evaluation method, reliability, defect proneness and functional correctness and consistency are deemed far less important than maintainability. However there are many studies that try to predict and decrease defects early in the design phases. One possible interpretation is that quality evaluation methods, as we said before, are not seen as a replacement for Software Quality Assurance and try to establish a way to measure and compare different designs that are semantically equivalent, that is, built for the same functional requirements, and mostly correct (defect-free). Given the resulting figures a statistical analysis was not considered relevant. Only two studies were considered relevant to our study and they will be summarized. Table 4 shows the use these studies and the other two full models make of the OO micro architecture knowledge, only those elements that have appeared at, at least, one of the studies is listed. 522

7 IADIS International Conference e-society 2006 Table 4. Use of OO knowledge in the four full models Principles Patterns Heuristics Bad smells Bansiya & Davis No No No No Barber & Graser No Indirectly Yes No Marinescu & Ratiu (2004) No Partially No Yes Miller, Hsia & Kung Yes No No No Bansiya and Davis QMOOD Bansiya and Davis (2002) propose a model for the assessment of high level design quality attributes in object oriented designs called Quality Model for Object-Oriented Design (QMOOD). It has four levels: OO design components (level 4 or L 4 ), OO design metrics (level 3 or L 3 ), OO design properties (level 2 or L 2 ) and finally design quality attributes (level 1 or L 1 ), and links between adjacent levels, L 34 (from L 4 to L 3 ), L 23 (from L 3 to L 2 ) and L 12 (from L2 to L 1 ). In each of the links Bansiya and Davis identify explicit relation between components of both levels, for L23 the mapping is exactly one to one, one metric for each of the OO properties (design size, hierarchies, abstraction, encapsulation, coupling, cohesion, composition, inheritance, polymorphism, messaging and complexity), and in L12 the mapping is even more explicit because each quality attribute (from ISO 9126) is the result of the sum of each of the calculate metrics multiplied by its weight. For instance, Reusability equals (0.25*Coupling +0.25*Cohesion+ 0.5*Messaging +0.5*Design Size). The weights can be positive or negative and are calculated intuitively. In fact, the study states that the weights, as well as other mappings, can be changed to reflect the goals of the organization. The relative importance of each quality attribute is not stated and is left to the designer s decision. Finally, models of OO knowledge such as design patterns, principles, and refactoring are not taken into account Barber and Graser s RARE The Barber and Graser (2000) study is not strictly speaking a quality evaluation model or method but a tool for creating evaluation models by specifying which quality attributes are targets for the designer. This tool is called RARE (Reference Architecture Representation Environment). Barber and Graser state that quality attributes impact each other, and that not all of them can be maximized at the same time. Therefore the designer must explicitly solve the conflicts that arise. The idea behind this study is that no single quality model can be established, given that, for instance, flexibility or extensibility will negatively impact on performance, and there are application domains where either could be more important. The study mentions reusability, extensibility, comprehensibility and performance as the main quality attributes to work with, although it does not imply that others cannot be added. As in other models, there are mappings that drive calculations from OO design metrics to quality attributes, but in this case the intermediate elements are OO knowledge elements: heuristics and strategies (as refactorings and design transformations that guide the application of heuristics). Thus Barber and Graser incorporate OO knowledge not as a goal, like in (Miller et al., 1999), but rather as a tool to achieve quality attribute enhancement. The quality attributes chosen by the designer, and their associated importance weights are quality goals; the metrics calculate the degree of achievement of the heuristics that are used to calculate the level of achievement of the goals. This tool uses strategies to help the designer change design in order to increase certain heuristics, and the order in which they are suggested to the designer is driven by the goals. Unfortunately the study talks about a tool still under construction and, in our searches, we have not encountered further information about it. No quantitative measures are given in the paper about the calculation of each heuristic, and no list of heuristics or strategies is given. For that reason, although the study is promising, we must discard it as incomplete. 523

8 ISBN: X 2006 IADIS 4. CONCLUSIONS We can conclude that there are already works in the literature that have provided specific metrics based only on design. However few provide a full method for design quality evaluation. The two studies detailed in this paper are focused on maintainability only. Indeed, an important conclusion of our review is that maintainability is the high-level quality indicator most frequently used, which is logical given that Object Orientation has been seen as a paradigm that favours flexibility and reuse. Other quality indicators or attributes, such as efficiency or portability, are missing in the full models. This could be due to the fact that all the studies are biased since they do not consider different application domains. Only four studies establish a full quantifiable quality evaluation model and none of them establishes an explicit hierarchy between the high-level indicators. Only two can be applied to design entities exclusively. In future works, two main objectives can be targeted: first, trying to establish hierarchies between quality attributes, maybe according to different hierarchy sets corresponding to application domains; and second, defining a better application of OO micro-architecture knowledge in the construction of the evaluation methods, through the use of ontologies. REFERENCES Software Design, Part 2. In IEEE Software, Vol. 21, No. 6, pp. c3. Abran, A., et al., Guide to the Software Engineering Body of Knowledge Version. SWEBOK, IEEE Press. Bansiya, J. & Davis, C. G., A hierarchical model for object-oriented design quality assessment. In Software Engineering, IEEE Transactions on, Vol. 28, No. 1, pp. 4. Barber, K. S. & Graser, T. J., Tool support for systematic class identification in object-oriented software architectures. 37th International Technology of Object-Oriented Languages and Systems. TOOLS-Pacific. Sydney, NSW, Australia, pp Briand, L. C., et al., Exploring the relationships between design measures and software quality in object-oriented systems. In Journal of Systems and Software, Vol. 51, No. 3, pp Brown, W. J., et al., Antipatterns: Refactoring Software, Architectures and Projects in Crisis, John Wiley \& Sons. Clements, P., et al., Evaluating Software Architectures. Methods and Case Studies, Addison-Wesley. Chidamber, S. R. & Kemerer, C. F., Towards a metrics suite for object oriented design. OOPSLA '91: Conference proceedings on Object-oriented programming systems, languages, and applications. New York, NY, USA, pp Fowler, M., Refactoring: Improving the design of existing code, Addison-Wesley. Gamma, E., et al., Design patterns: elements of reusable object-oriented software, Boston, MA, USA, Addison- Wesley Longman Publishing Co., Inc. Garzás, J. & Piattini, M., An Ontology for Microarchitectural Design Knowledge. In Software, IEEE, Vol. 22, No. 2, pp. 28. Henderson-Sellers, B., et al., Coupling and Cohesion (Towards a Valid Metrics Suite for Object Oriented Analysis and Design). In Object Oriented Systems, Vol. 3, No. pp Humphrey, W. S., Managing the software process, Boston, MA, USA, Addison-Wesley Longman Publishing Co., Inc. ISO/IEC, ISO/IEC :2001(E). Software engineering -- Product quality -- Part 1: Quality model. Geneva, Switzerland. Kitchenham, B., Procedures for Performing Systematic Reviews. Software Engineering Group, Department of Computer Science, Keele University and Empirical Software Engineering National ICT Australia Ltd. Li, W. & Henry, S., Maintenance metrics for the object oriented paradigm. Software Metrics Symposium. pp. 52. Marinescu, R. & Ratiu, D., Quantifying the quality of object-oriented design: the factor-strategy model. pp Miller, B. K., et al., Object-oriented architecture measures. Hawaii International Conference on System Sciences. pp. 10 pp. Paulk, M., et al., Capability Maturity Model for Software (Version 1.1). Software Engineering Institute, Carnegie Mellon University. Purao, S. & Vaishnavi, V., Product metrics for object-oriented systems. In ACM Comput. Surv., Vol. 35, No. 2, pp