Comparing service orientation and object orientation : a case study on structural benefits and maintainability

Service Orientation (SO) is a dominating technique evolving around the use of Object Orientation (OO). The conceptual comparison of both the approaches have been broadly explained in the literature, but the generalizable comparison of the maintainability of two paradigms is still a topic under research. This thesis tries to provide a generalized comparison of the maintainability using two functionally equivalent Online BookStore systems developed with Service Orientation and Object Orientation. This thesis presents a brief explanation of the software metrics used for the comparison. The quantitative comparison revealed that the Service-Oriented version of the system has a lower coupling and higher cohesion between software modules compared to an Object-Oriented approach. Through survey results, it was found that Service Orientation has a better degree of modifiability, encapsulation and abstraction while Object-Orientation provides a reduced degree of testing and system complexity comparatively. Also in expert interviews, participants believe that systems based on service orientation possess a better degree of stability, analyzability and modifiability whereas Object-Oriented System tends to provide a lower degree of structural complexity. Furthermore, experimental results suggest that a Service-Based System has a better degree of extensibility and changeability compared to Object-Oriented System

A comparison of CK and Martin's package metric suites in predicting reusability in open source object-oriented software

Packages are units that organize source code in large object-oriented systems. Metrics used at the package granularity level mostly characterize attributes such as complexity, size, cohesion and coupling. Many of these characterized attributes have direct relationships with the quality of the software system being produced. Empirical evidence is required to support the collection of measures for such metrics; hence these metrics are used as early indicators of such important external quality attributes. This research compared the CK and Martin’s package metric suites in order to characterize the package reusability level in object-oriented software. Comparing the package level of metrics suites as they measure an external software quality attribute is supposed to help a developer knows which metric suite can be used to effectively predict the software quality attribute at package level. In this research two open source Java applications, namely; jEdit and BlueJ were used in the evaluation of two package metrics suites, and were compared empirically to predict the package reusability level. The metric measures were also used to compare the effectiveness of the metrics in these package metrics suites in evaluating the reusability at the package granularity level. Thereafter metric measures of each package were normalized to allow for the comparison of the package reusability level among packages within an application. The Bansiya reusability model equation was adapted as a reusability reference quality model in this research work. Correlation analysis was performed to help compare the metrics within package metrics suites. Through the ranking of the package reusability level, results show that the jEdit application has 30% of its packages ranked with a very high reusability level, thus conformed to the Pareto rule (80:20). This means that the jEdit application has packages that are more reusable than packages in the BlueJ application. Empirically, the Martin’s package coupling metric Ce with an r value of 0.68, is ranked as having a positive strong correlation with RL, and this has distinguished the Martin’s package metrics suite as an effective predictor of package reusability level from the CK package metrics suite

Comprehension of object-oriented software cohesion: The empirical quagmire

Chidamber and Kemerer (1991) proposed an object-oriented (OO) metric suite which included the Lack of Cohesion Of Methods (LCOM) metric. Despite considerable effort both theoretically and empirically since then, the software engineering community is still no nearer finding a generally accepted definition or measure of OO cohesion. Yet, achieving highly cohesive software is a cornerstone of software comprehension and hence, maintainability. In this paper, we suggest a number of suppositions as to why a definition has eluded (and we feel will continue to elude) us. We support these suppositions with empirical evidence from three large C++ systems and a cohesion metric based on the parameters of the class methods; we also draw from other related work. Two major conclusions emerge from the study. Firstly, any sensible cohesion metric does at least provide insight into the features of the systems being analysed. Secondly however, and less reassuringly, the deeper the investigative search for a definitive measure of cohesion, the more problematic its understanding becomes; this casts serious doubt on the use of cohesion as a meaningful feature of object-orientation and its viability as a tool for software comprehension

Complexity and maintenance : a comparative study of object-oriented and structured methodologies : a thesis presented in partial fulfilment of the requirements for the degree of Master of Business Studies in Information Systems at Massey University

Maintenance has been found to be one of the most expensive phases in the life of an information system. It has been suggested that the use of object-oriented methods instead of traditional structured methods may be one way of reducing the cost of maintenance required for an information system. This thesis is an attempt to determine whether the object-oriented approach does in fact undergo a relatively smaller increase in complexity when subjected to a change in specifications than a similar system that is developed using a "structured methodology", and is therefore easier to maintain. The methodologies used in this study were Yourdon's (1989) Modern Structured Methodology and Booch's (1994) Object-Oriented methodology. The analysis phase of both methodologies were applied to the same case study twice in order to evaluate the effects of a change in the system's specifications. Once the two models for each methodology were complete, various metrics were applied to the structured system and a separate set of metrics were applied to the object-oriented system. The results of the models and the metrics were then analysed and validated in order to determine which system suffered a smaller proportional increase in complexity as a result of the changes to the system. It was found that overall, the object-oriented system proved to undergo a smaller increase in complexity, and it was therefore easier to maintain as a result of the changes than the structured system

Using a Combination of Measurement Tools to Extract Metrics from Open Source Projects

Software measurement can play a major role in ensuring the quality and reliability of software products. The measurement activities require appropriate tools to collect relevant metric data. Currently, there are several such tools available for software measurement. The main objective of this paper is to provide some guidelines in using a combination of multiple measurement tools especially for products built using object-oriented techniques and languages. In this paper, we highlight three tools for collecting metric data, in our case from several Java-based open source projects. Our research is currently based on the work of Card and Glass, who argue that design complexity measures (data complexity and structural complexity) are indicators/predictors of procedural/cyclomatic complexity (decision counts) and errors (discovered from system tests). Their work was centered on structured design and our work is with object-oriented designs and the metrics we use parallel those of Card and Glass, being, Henry and Kafura's Information Flow Metrics, McCabe's Cyclomatic Complexity, and Chidamber and Kemerer Object-oriented Metrics

An Empirical Study of a Repeatable Method for Reengineering Procedural Software Systems to Object- Oriented Systems

This paper describes a repeatable method for reengineering a procedural system to an object-oriented system. The method uses coupling metrics to assist a domain expert in identifying candidate objects. An application of the method to a simple program is given, and the effectiveness of the various coupling metrics are discussed. We perform a detailed comparison of our repeatable method with an ad hoc, manual reengineering effort based on the same procedural program. The repeatable method was found to be effective for identifying objects. It produced code that was much smaller, more efficient, and passed more regression tests than the ad hoc method. Analysis of object-oriented metrics indicated both simpler code and less variability among classes for the repeatable method

Assessing architectural evolution: A case study

This is the post-print version of the Article. The official published can be accessed from the link below - Copyright @ 2011 SpringerThis paper proposes to use a historical perspective on generic laws, principles, and guidelines, like Lehman’s software evolution laws and Martin’s design principles, in order to achieve a multi-faceted process and structural assessment of a system’s architectural evolution. We present a simple structural model with associated historical metrics and visualizations that could form part of an architect’s dashboard. We perform such an assessment for the Eclipse SDK, as a case study of a large, complex, and long-lived system for which sustained effective architectural evolution is paramount. The twofold aim of checking generic principles on a well-know system is, on the one hand, to see whether there are certain lessons that could be learned for best practice of architectural evolution, and on the other hand to get more insights about the applicability of such principles. We find that while the Eclipse SDK does follow several of the laws and principles, there are some deviations, and we discuss areas of architectural improvement and limitations of the assessment approach