A novel approach to formalize Object-Oriented ... - Semantic Scholar

Download PDF
21 downloads 100315 Views 215KB Size Report
Comment
Among the metrics of the key phases in the software development life cycle (SDLC), .... alternative to the creation of bespoke parsing applications to access and ...
A novel approach to formalize Object-Oriented Design Metrics Mohamed M. El-Wakil, Ali El-Bastawisi, Mokhtar B. Riad Information Systems Department

Ali A. Fahmy Computer Science Department

Faculty of Computers and Information Cairo University – Cairo Egypt {m.elwakil, a.elbastawesy, m.boshra, a.fahmy}@fci-cu.edu.eg Abstract Despite the extensive and solid research literature on Object-Oriented Design Metrics (OOD Metrics), a recent survey that was conducted to assess the exploitation of metrics collection and analysis in the design phase within the software industry in Sweden [1], indicated that only 21% of the survey respondents collect metrics in the design phase. 55% of the respondents to the same survey said that they consider metrics collection as a difficult process. A major reason of the difficulty of collecting design metrics is the lack of a common syntax or a common language to express OOD metrics. This lack resulted in shortage of tools that automate collecting design metrics. Researchers who propose OOD metrics express them in plain English or as mathematical formulas. Plain English allows different interpretations for the same metric. Mathematical formulas should be based on a mathematical model, which does not exist for ObjectOriented designs. In this paper, we propose expressing metrics as XQuery expressions that targets XMI documents. XMI documents offer a standard way for representing object-oriented designs, specifically UML diagrams. Also, we present Design-Metrics Crawler, which is a software tool that applies our proposal. Keywords: Metrics, XMI, UML, XQuery, object-oriented design 1. Introduction Since the famous statement "What is not measurable make measurable" [17] of Galileo Galilei (1564 - 1642) it has been a major goal in science to quantify observations as a way to understand and control the underlying causes. Computer science is no exception. Software metrics are the computer science instruments for applying Galileo’s advice. Among the metrics of the key phases in the software development life cycle (SDLC), the design phase metrics got most of the attention. Design is an important cost driver in software development, since it heavily affects the cost of producing the following phases, i.e. coding. Even though that the design phase would consume 5-10% of the effort incurred during the whole SDLC, but up to 80% of the total effort would go in fixing a bad design [2]. Over and above, If bad design is not fixed in the design phase, the cost for fixing it after delivery of the software is between 5 and 100 times higher [3]. Most of the work in this area of OOD metrics aims at proposing new metrics [4, 5, 6, 7, 8, 9, 10, 11], validating existing ones [12, 13, 14, 15, 16], and finding applications for metrics. There are many applications for OOD metrics, such as automated design flaws detection [18, 19, 20,21] identifying key classes in a legacy system [22], system-level fault-proneness and effort 1

prediction[23, 24,25, 26], enhancing the visualization of the design diagrams [27] and estimating design quality [28, 29, 30, 31]. In spite of the broad range of metrics applications, metrics collection and analysis is not a common practice in the software industry. A recent survey [1] that aimed at assessing the usage of design metrics in industry concluded that the majority of software engineers “respect” metrics and are “in favor” of metrics, but only 21% of them collect metrics! The justification for this situation is that metrics outcome is not clear to engineers, and that they are difficult to collect, even automatically i.e. using current software for metrics collection. The burden involved in automating collecting metrics is due to one major reason: There is no agreed-upon syntax for representing metrics. There is no formal reference model for precise metric definition [32]. 2. Literature review Surprisingly, limited effort was spent on tackling this problem. Baroni and Abreu proposed using OCL (Object Constraint Language) [33] statements to describe OOD metrics based on UML class diagrams. They built FLAME (Formal Library for Aiding Metrics Extraction) [34] which is a library of metrics definitions formulated as OCL statements. The approach of using OCL has many advantages such as being dependant on standardized notations that are both precise and formal. That eases the process of collecting metrics from UML class diagrams. However, it has some drawbacks; for example, the OCL is intended to describe constraints, not queries. That leads to complicated definitions of metrics, and the inability to define complex metrics. Also, since OCL is based on UML, it could not be used to represent metrics for any other OOD representation (e.g. design diagrams produced by reverse engineering Java or C code). The ODEM (Object-Oriented Design Model) [32] is another approach proposed by Reißing. This approach is based on introducing a new formal model that captures UML class diagrams elements. This model is an abstraction layer defined on the top of the UML meta-model. Ralf claims that his layer makes metrics definitions easier to read and understand [32]. However, this approach lacks the precision required, since the proposed layer consists of plain English expressions, as shown in Figure 1. DIT(c) = If NSC(c) > 0 then max c'∈C: extends(c,c') {DIT(c') + 1} else 0 endif Where NSC (number of (direct) super classes) is defined as: NSC(c) = |{c'∈C: extends(c,c')}| Figure 1: Example of a metric (DIT1) expressed using ODEM Evaluating the existing approaches for finding an appropriate syntax for representing metrics, leads to the elicitation of some desirable properties that should be met by any potential language for representing metrics. This language should be a standard language with a formal syntax to gain wide acceptance among practitioners. It should be easy to express metrics in terms of such a language. Also, it should be straightforward to automate metrics collection defined in this language.

1

DIT is the maximum length from the current class to the root of the tree.

2

3. Our approach The basic idea of our approach is to view design documents as data, and metrics as queries on this data. Hence, metrics could be expressed and collected using a query language that can target design documents expressed in query-able format. Here comes the role of XMI. XMI [39] is an XMLbased file format that is being used to represent design documents (e.g. UML class diagrams). Representing class diagrams as XMI allows representing and collecting class diagram metrics using a query language that can query XML documents. XML has two languages which could be used to query its data: XSLT [35] and XQuery [36]. Both languages depend on XPath language [37] to select XML nodes. However, XSLT was not intended primarily to be a query language, and is very slow handling relatively large XML files (files with size in terms of mega bytes) [38]. XSLT was developed to be a language for specifying transformations of an XML source document to one or more outputs providing a lightweight alternative to the creation of bespoke parsing applications to access and modify the XML document. So, we are left with XQuery, which we found to be a good language for expressing metrics, and the best alternative for extracting metrics values. Using XQuery to express metrics and extract measures have many advantages such as: Preciseness: XQuery enjoys a well-defined and standardized data model and formal syntax, hence metrics expressed using it will not exhibit the ambiguity usually found in metrics expressed using plain English. Capability to express complex metrics: Besides being a query language, XQuery offers programming languages-like capabilities such as variables, looping, and branching. Thus allowing users to express what so ever metrics regardless of their complexity. This is an advantage that other proposed metrics representation alternatives (OCL [33] and ODEM [32]) lack. Easy to convert into automated code: XQuery expressions are executable by themselves, so there is no need to convert them to any other format before execution. Standardized: XMI is an OMG standard, and XQuery is a W3C standard. Employing already existing standards guarantees acceptance among practitioners. Both are gaining increasing popularity nowadays. XMI importing and exporting functionally is becoming a standard functionally in the UML modeling tools such as Rational Rose [40], Poseidon for UML [41], and Borland Together [R43]. XQuery will be a standard query language besides SQL in the next version of Microsoft SQL Server [42]. Wide applicability: XMI is not intended to represent UML diagrams only, but any MOF-complaint diagram (e.g. ERDs); hence metrics that target diagrams other than UML ones could be expressed using XQuery. Also, XMI is used to represent reverse-engineered object-oriented code, such as Java and Smalltalk, allowing extracting measures from such code after being converted to XMI. Figure 2 shows an example of using XQuery to encode object-oriented design-metrics: declare namespace UML = "org.omg.xmi.namespace.UML" ; declare function local:GetParentIDByID($cls_id) {input()//XMI//UML:Generalization/UML:Generalization.child/UML:Class[@xmi.idref=$c ls_id]/../../UML:Generalization.parent/UML:Class/@xmi.idref}; declare function local:GetAnsc($cls_id,$chs) { 3

if ($cls_id = ()) then $chs else for $r in $cls_id let $j := local:GetParentIDByID($r) let $chn := $chs | $j return $chn | local:GetAnsc($j,$chn ) }; declare function local:DIT($cls_id) {count(local:GetAnsc($cls_id,()))+1}; Figure 2: Example of a metric (DIT) expressed using XQuery 4. Design-metrics crawler To prove the feasibility of the proposed approach, a tool that uses metrics encoded as XQuery expressions to extract measures was developed (Design-Metrics Crawler or DM Crawler). This section presents the requirements specifications and the implementation details of this tool. DM Crawler is a software tool that collects, stores, displays and analyzes object-oriented design measures from XMI files using XQuery expressions. It consists of three main modules: metrics manipulation module, design documents manipulation module, and measures analysis module. Each one of them is described in the following subsections. Figure 3 illustrates the overall structure of DM Crawler.

Figure 3: The overall structure of DM Crawler 4.1 DM Crawler data model DM Crawler stores the metrics definitions and the extracted measures in a relational database; the ER diagram of this database is depicted in figure 4, following it the description of the tables and fields of the ER diagram.

4

Design D_ID D_Name D_Desc

Classes

ClassDiagram

Class_Ref Class_Name

CD_ID CD_Run_DT CD_FilePath CD_XMI CD_Ver

Class_Metrics_Values CMV_Value

Diagram_Metrics_Values DMV_Value

Metrics Metric_Acronym Metric_Name Metric_Description Metric_XQuery Metric_Scope Metric_Level Metric_Ignore

XQs

OO_Props

XQ_ID XQ_Desc XQ_Expression

Prop_ID Prop_Desc

Figure 4: ER diagram of the database used by DM Crawler Table XQs is used to store XQuery expressions that may be needed for purposes other extracting measures. Currently one XQuery expression is stored in this table. The GetClasses XQuery expression which extracts the list of classes. XQ_ID is the primary key of this table, XQ_DESC stores the description of the XQuery expressions, which is stored itself in the field XQ_EXPRESSION Design documents data are stored in three tables; “DESIGN” table stores the name and the description of a design document. D_ID is the key of this table, D_NAME field stores the name of the design document, and D_DESC shall store a brief description of the design document. “CLASSDIAGRAM” table stores more than class diagram instance for the same design document. This is useful when there is more than one instance (version) of the same design document. For each version, the file path of the XMI file, the version number, and the extraction process date and time are recorded. “CLASSES” table stores classes found in every processed design document version. CD_ID is a foreign key that refers to the “CLASSDIAGRAM” table; CLASS_REF is a unique identifier that is assigned to each class stored in XMI files by the XMI generator. CLASS_NAME is the name of the class. “METRICS” table keeps a record of all metrics supported by the tool. Along with the metric acronym (METRIC_ACRONYM), the metric full name (METRIC_NAME), description (METRIC_DESCRIPTION), scope (METRIC_SCOPE) (class or diagram), and the XQuery expression (METRIC_XQUERY) are stored. “CLASS_METRICS_VALUES” and “DIAGRAM_METRICS_VALUES” tables store the measures collected by the tool. In “DIAGRAM_METRICS_VALUES”, the METRIC_ACRONYM 5

is a foreign key that refers to the table “METRICS”, CD_ID is a foreign key that refers to the table “CLASSDIAGRAM”, DMV_VALUE is the measure of the metric referred to by METRIC_ACRONYM of the class diagram referred to by CD_ID. In “CLASS_METRICS_VALUES”, the METRIC_ACRONYM is a foreign key that refers to the table “METRICS”, CD_ID is a foreign key that refers to the table “CLASSDIAGRAM”, CLASS_REF is a foreign key that refers to the table “CLASSES”, CMV_VALUE is the measure of the metric referred to by METRIC_ACRONYM of the class identified with CLASS_REF. 4.2 Metrics manipulation module Metrics manipulation module is the part of DM Crawler that allows the user to add, modify, and remove metrics definitions from the database. A metric definition consists of the metric name, acronym, description, XQuery representation, scope (class or diagram metric), and the objectoriented property it measures. The most important part of the metric definition is the XQuery expression that extracts the metric measurements from the XMI files. There is one condition that must be met by the XQuery expressions, besides being a correct XQuery expression, to be compatible with the measures extraction algorithm {presented in 4.3}. This condition is that: XQuery expressions that extract class-level measures must contain one function that has one parameter named “$CLS_ID_PARM”. At the measures extraction time, this parameter will be replaced by the “id” of the current class. Figure 5 shows a sample of a metric definition, of the metric “Data Access Metric”, or DAM: Metric Acronym Metric Name Metric Description

: : :

DAM Data Access Metric The ratio of the number of private attributes to the total number of attributes in a class Class Encapsulation

Metric Scope : Metric OO property : Metric XQuery : declare namespace UML = "org.omg.xmi.namespace.UML" ;

declare function local:GetAttributesIDByVisibility ($cls_id, $visi) { //XMI/XMI.content/UML:Model/UML:Namespace.ownedElement//UML:Class[@xmi.id=$cls_id]/ UML:Classifier.feature/UML:Attribute[@visibility=$visi] }; declare function local:NVA($cls_id) {count(local:GetAttributesIDByVisibility($cls_id,"private"))}; declare function local:NRA($cls_id) {count(local:GetAttributesIDByVisibility($cls_id,"protected"))}; declare function local:NKA($cls_id) {count(local:GetAttributesIDByVisibility($cls_id,"package"))}; declare function local:NPA($cls_id) {count(local:GetAttributesIDByVisibility($cls_id,"public"))}; declare function local:DAM($cls_id) { if (local:NVA($cls_id) eq 0) then 0 6

else (local:NVA($cls_id) div (local:NVA($cls_id) + local:NRA($cls_id) + local:NKA($cls_id) + local:NPA($cls_id))) }; local:DAM($CLS_ID_PARM) Figure 5: Data Access Metric (DAM) expressed as XQuery DM Crawler comes with 65 metrics definition stored in its database. A list of these metrics and full definitions of them is available in [44]. 4.3 Design documents manipulation and measures extraction module Design documents manipulation module is the part of DM Crawler that handles design documents stored as XMI files. A design document may have more than one version; each version is called a “design diagram”. Design diagrams are treated independently, however, the measures extracted from the design diagrams of a given design document may be drawn on one chart to show trends of the metrics measures. This module performs two main functions: adding new design documents and their associated design diagrams to the database, and extracting the measures from the design documents. The user can add a design document by entering its name. A design diagram is added by associating it to a design document, and entering the path of the XMI file that stores the design diagram. The design diagrams themselves (XMI files) are not stored in the database. Only the path to the XMI files is stored. Measures extraction is the primary function of this tool. It runs metrics XQuery expressions stored in the relational database against the source XMI file that contains the design diagram. The XQuery execution produces files with the resulting measures. These files are then read, and the measures are stored in the database for further processing. The measures extraction part consists of the metrics XQuery expressions, the measures repository (relational database) and the algorithm that preprocesses XQuery expressions, executes them, then collects the resulting measures. Figure 6 shows the algorithm used in the extraction process, the full code is in [44]. For each Metric in MetricsList Set XQ= the XQuery expression of current metric If the scope of the current metric = Class then For each Class in the Diagram Modify XQ to suit the current class Execute the modified XQ Read the result of executing the modified XQ Add the result to the database Next Else Execute the XQ Read the results of executing XQ Add the result of executing XQ to the database End if Next Figure 6: Example DM Crawler extraction algorithm

7

4.4 Measures analysis module The measures analysis module is the GUI part of DM Crawler that helps the user analyzes the extracted measures. The user is presented with two views of the measures. One view is just a listing of the extracted measures. In this view, the user can view the measures grouped by the entity which the measure belongs to (either a class or a diagram). In another view, the user is presented with statistics computed from the stored measures, such as maximum, minimum, mean, standard deviation, and the variance. Also, a histogram is drawn in this view. Also, extracted measures could be used to generate useful information. For instance: detecting structural flaws, detecting bad smells, identifying outliers and predicting fault-proneness of classes. Structural flaws are omissions that may be accidental or intended. The number of associations per class metric is used to identify classes with no associations, total number of methods metric is used to identify classes with no methods at all, and total number of attributes metric is used to identify classes with no attributes. Total number of attributes metric and the total number of methods metric are combined to identify empty classes. Bad smells, or design flaws are structural characteristic of a design entity or design fragment that expresses a deviation from a given set of criteria typifying the high-quality of a design [20]. These bad smells include misplaced classes [46], data classes [47] and god classes [47]. The developed tool can detect misplaced classes, god classes and data classes design flaws. A misplaced class: is a class that accesses classes from outside its package more than it accesses classes from its package. This situation is detected through coupling metrics such as OCMIC and OCMEC [45]. Data-classes are dumb data holders and almost certainly other classes are strongly relying on them. The lack of functional methods may indicate that related data and behavior are not kept in one place; this is a sign of an improper data abstraction. Data classes impair the maintainability, testability and understandability of the design. In a good object-oriented design, the intelligence of a system is uniformly distributed among the top-level classes. God classes refer to those classes that tend to centralize the intelligence of the system. An instance of a god-class performs most of the work, delegating only minor details to a set of trivial classes and using the data from other classes. God-classes deviate from the principle of manageable complexity as they tend to capture more than one abstraction consequently; such pathological classes tend to be also non-cohesive. Thus, god-classes have a negative impact on the reusability and the understandability of that part of the system that they belong to. Also, DM Crawler applies a model that predicts the probability that a class will have a fault (faultproneness). This model was proposed by El Emam in [48]. This model takes as input three metrics: depth of inheritance tree (DIT), total number of attributes (TNA) and the number of other classes that have methods with parameter types of this class (OCMEC). The model formula is depicted in Equation 1. The π value is the predicted probability of fault-proneness.

∏=

1 1 + e −3.97 + 0.464TNA+1.47 OCMEC +1.06 DIT Equation 1: El Emam model for predicting fault-proneness

8

Additionally, DM Crawler offers the ability to detect outliers incidents. Outliers incidents are classes with measures that exceed user-set thresholds. For example, the user can select to detect classes with the highest 10% measures of the depth of inheritance tree metric, or the lowest 5 measures of the total number of methods metric. An ideal application of DM Crawler is when software engineers can assess the conformance to design rules by design metrics giving immediate feedback when design rules have been violated. 5. Conclusion Software metrics have evolved with software engineering over the past decades. Since the emergence of the object-oriented paradigm, object-oriented metrics have been developed next to traditional metrics. Object-oriented metrics differ from traditional metrics due to the fact that they follow a development approach that is characterized by structuring systems into classes and objects. The benefits of both traditional and object-oriented metrics have been proved by researchers. These benefits are to understand, control, predict and improve the software engineering process and its artifacts. The focus of this work is object-oriented metrics in the design phase. The design phase is an early stage of the software life cycle in which the benefits of software metrics can already be perceived. A prominent problem with metrics is the lack of a precise language, or grammar to describe them. The most used way for expressing metrics is plain English. Plain English lacks the formality and precision needed to convey the exact meaning of the metrics. This complicates building tools that extract metrics measures from software artifacts such as design. This shortage of tools hinders practitioners from employing metrics in their software engineering process. Using XQuery to represent metrics, not only solves the problem of expressing metrics, but also eases building tools that extract measures from design artifacts. We perceive this as the most important advantage of using XQuery in comparison with the other approaches. A tool that uses XQuery expressions for measures extraction could be easily modified to support new metrics, just by expressing them in XQuery expressions, then adding them to the library of metrics supported by the tool. The developed tool “Design-Metrics Crawler” is an implementation of the idea proposed above, with XQuery expressions stored in a database, extracting measures requires only retrieving the metric definition from the database, then running it against an XMI file, then collecting the resultant measure. An addition that distinguishes “Design-Metrics Crawler” from other tools that extract measures from XMI files is the post-extraction functions. The developed tool can be used to detect design bad smells, detect structural flaws, identify classes with outliers measures, and to predict the fault-proneness of classes. 6. Future work Use of other UML diagrams as Input In this work we were mainly concerned about design measures extracted from UML class diagrams. We are planning to investigate which are relevant metrics for dealing not only with the static structure of models, but also with its behavior. For such metrics, possibilities of metrics formalization (and even creation) based on other UML diagrams can be investigated. Employing the developed tool in a real software project The benefits of the developed tool would not be fully realized, until used in an industrial software development project. This would help assessing the applicability of the proposed idea in the real world. 9

Studying the effect of object-oriented features on ease of implementation Definitely, coupling, cohesion, inheritance, encapsulation, and other object-oriented features affect effort and time spent on implementing a given design. But, what is the nature of this effect? For example, does using inheritance reduce implementation time or effort or increase it? Using inheritance allows reuse, however, it increases the cognitive complexity needed to understand a class deep in the inheritance tree. Such a study would result in a sort of thresholds or optimal ranges for metrics such as depth of inheritance tree and number of sub-classes. References: [1] S. Löper, and M. Zehle , "Evaluation of Software Metrics In the Design Phase and Their Implication on CASE Tools." , Master Thesis, Department of Software Engineering and Computer Science, Blekinge Institute of Technology, Sweden , 2003. [2] D. Bell, “Software Engineering: A Programming Approach”, New York: Addison-Wesley, 2000. [3] B. Boehm, and V. Basili, “Software Defect Reduction Top 10 List”, IEEE Computer, 34(1), 135-137, 2001. [4] J. Bansiya, and C. Davis, "A Hierarchical Model for Object-Oriented Design Quality Assessment", IEEE Transactions On Software Engineering, Vol. 28, No. 1, 2002. [5] H. Kim and C. Boldyreff, "Developing Software Metrics Applicable to UML Models”, 6th ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE 2002), 2002. [6] M. Genero, M. Piattini and C. Calero , "Early measures for UML class diagrams" , L'OBJET: Software, Databases, Networks, Volume 6, Number 4 , 2000. [7] R. S. Chidamber and C. F. Kemerer , "A Metrics Suite For Object Oriented Design" , IEEE Transactions on Software Engineering, Vol. 20, No. 6. , 1994. [8] F. B. Abreu and R. Carapuça, "Object-Oriented Software Engineering: Measuring and Controlling the Development Process”, 4th Int. Conf. On Software Quality, McLean, VA, USA, 3-5 October 1994, 1994. [9] M. Lanza and S. Ducasse , "Beyond Language Independent object-oriented Metrics: Model Independent Metrics" , 6th ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE 2002) , 2002. [10] L Badri, and M. Badr “A New Class Cohesion Criterion: An empirical study on several systems”, 7th ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE'2003), Germany, 2003 [11] P. In, S. Kim, and M. R. Barry, “UML-based Object-Oriented Metrics for Architecture Complexity Analysis”, Ground System Architecture Workshop (GSAW2003), California, USA, March 4 - 6, 2003 [12] M. Shepperd and D. Ince , "Derivation and Validation of Software Metrics" , Oxford: Oxford University Press, ISBN: 0198538421 , 1993. 10

[13] V. R. Basili , L. C. Briand and W. L. Melo , ”Validation of Object-Oriented Design Metrics as Quality Indicators”, IEEE transactions on software engineering, vol. 22, no. 10, October 1996. [14] F. B. Abreu and W. Melo, ”Evaluating the Impact of Object-Oriented Design on Software Quality”,3rd Int’l S/W Metrics Symposium, Berlin, Germany, March 1996. [15] M. Genero, and M. Piattini, ”Empirical validation of measures for class diagram structural complexity through controlled experiments”, 5th International ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering, 2001 [16] K. El Emam, S Beniarbi, N. Goel, and S. Rai, ”A Validation of Object-oriented Metrics” , National Research Council Canada Internal Report No. 43607, 1999. [17] Kelvin, W. T. Popular Lectures and Addresses, 1884 [18] H. A. Sahraoui, R. Godin, and T. Miceli, “Can Metrics Help to Bridge the Gap Between the Improvement of OO Design Quality and Its Automation?” , International Conference on Software Maintenance (ICSM'00), San Jose, California, October 11 - 14, 2000. [19] H. Bär and O. Ciupke, “Exploiting design heuristics for automatic problem detection”, ObjectOriented Technology (ECOOP'98 Workshop Reader), Lecture Notes in Computer Science 1543, 1998. [20] R. Marinescu, “Using Object-Oriented Metrics for Automatic Design Flaws Detection in Large Scale Systems”, ECOOP Workshop Reader, 1998. [21] R. Marinescu, “Detecting Design Flaws via Metrics in Object-Oriented Systems”, Proceedings of the TOOLS USA 39, Santa Barbara, USA, 2001. [22] M. Lanza, et al. The FAMOOS Object Oriented Reengineering Handbook, Internal report/report - Research center computer science, Karlsruhe 1999. [23] W. Evanco, “Poisson Analyses of Defects for Small Software Components”, Journal of Systems and Software, 38, 27-35, July 1997 [24] K. El-Emam, W. Melo, and J. Machado, “The Prediction of Faulty Classes Using ObjectOriented Design Metrics”, Journal of Systems and Software 1999 [25] L. Briand, and J. Wuest, “The Impact of Design Properties on Development Cost in ObjectOriented Systems”. International Software Engineering Research Network, 1999 [26] P. Yu, T. Systa, and H. Muller, “Predicting Fault-Proneness using OO Metrics: An Industrial Case Study”, Sixth European Conference on Software Maintenance and Reengineering, Budapest, Hungary, March 11 - 13, 2002. [27] R. Kollmann and M. Gogolla, “Metric-Based Selective Representation of UML Diagrams”, Sixth European Conference on Software Maintenance and Reengineering, Budapest, Hungary, March 11 - 13, 2002 [28] J. Bansiya and C. G. Davis, “A Hierarchical Model for Object-Oriented Design Quality Assessment” , IEEE Transactions On Software Engineering, Vol. 28, No. 1, January 2002.

11

[29] F. B. Abreu and W. Melo, “Evaluating the Impact of Object-Oriented Design on Software Quality”, 3rd International Software Metrics Symposium (METRICS '96), Berlin, Germany, March 25 - 26, 1996. [30] L. Briand, J. Wüst, John W. Daly, V. Porter, "Exploring the Relationships between Design Measures and Software Quality in Object-Oriented Systems", Journal of Systems and Software, 51(2000) p 245-273. [31] M. Genero, L. Jiménez and M. Piatti, “A Prediction model for OO information system quality based on early indicator”, 5th East-European conference Proceeding On Advances in Databases and Information Systems, 2001. [32] R. Reißing, "Towards a Model for Object-Oriented Design Measurement”, 5th ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE 2001) , 2001. [33] A. L. Baroni, and F. B. Abreu, "An OCL-Based Formalization of the MOOSE Metric Suite”, 7th ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE' 2003), 2003. [34] A. L. Baroni, F. B. Abreu , "A Formal Library for Aiding Metrics Extraction" , 4th International Workshop on OO Reengineering, Darmstadt (Germany) , 2003. [35] W3C, "XSL Transformations (XSLT) Version 1.0”, 1999, http://www.w3.org/TR/xslt [36] W3C, "W3C XQuery homepage”, accessed 2005, http://www.w3.org/XML/Query. [37] W3C, "XML Path Language (XPath) Version 1.0”, 1999, http://www.w3.org/TR/xpath. [38] D. Carlson, "Modeling XML applications with UML: practical e-business applications”, Addison Wesley. ISBN 0201709155 , 2001. [39] OMG , "OMG XMI “http://www.omg.org/technology/documents/formal/xmi.htm.

homepage"

,

2002,

[40] IBM Rational Rose site, Accessed 2005, www-306.ibm.com/software/rational/. [41] Gentleware AG site , "Posiedon for UML" , Accessed 2005, http://www.gentleware.com/. [42] B. Beauchemin , "XML IN YUKON: New Version Showcases Native XML Type and Advanced Data Handling", Accessed 2004, http://msdn.microsoft.com/msdnmag/issues/04/02/xmlinyukon/default.aspx. [43] Borland Together Control Center site, "Together Control Center”, Accessed 2005 www.borland.com/together/. [44] M. El Wakil, "XMI Data Management: Design-Metrics Extraction and Analysis", M. Sc. Thesis, Cairo University, Cairo, Egypt, 2004. [45] L. Briand, P. Devanbu, and W. Melo, , "An Investigation into Coupling Measures for C++" , Proceedings Of the 19th International Conference on Software Engineering. , 1997.

12

[46] R. Marinescu. Detecting Design Flaws via Metrics in Object- Oriented Systems. In Proceedings of TOOLS USA 2001, pages 103–116. IEEE Computer Society, 2001. [47] A.J. Riel. , "Object-Oriented Design Heuristics." , Addison-Wesley Professional, ISBN: 020163385X , 1996. [48] K. El-Emam, W. Melo, and J. Machado, "The Prediction of Faulty Classes Using ObjectOriented Design Metrics.”, Journal of Systems and Software, Volume 56 , Issue 1. , 2001.

13