14,556 research outputs found
A Parsing Scheme for Finding the Design Pattern and Reducing the Development Cost of Reusable Object Oriented Software
Because of the importance of object oriented methodologies, the research in
developing new measure for object oriented system development is getting
increased focus. The most of the metrics need to find the interactions between
the objects and modules for developing necessary metric and an influential
software measure that is attracting the software developers, designers and
researchers. In this paper a new interactions are defined for object oriented
system. Using these interactions, a parser is developed to analyze the existing
architecture of the software. Within the design model, it is necessary for
design classes to collaborate with one another. However, collaboration should
be kept to an acceptable minimum i.e. better designing practice will introduce
low coupling. If a design model is highly coupled, the system is difficult to
implement, to test and to maintain overtime. In case of enhancing software, we
need to introduce or remove module and in that case coupling is the most
important factor to be considered because unnecessary coupling may make the
system unstable and may cause reduction in the system's performance. So
coupling is thought to be a desirable goal in software construction, leading to
better values for external software qualities such as maintainability,
reusability and so on. To test this hypothesis, a good measure of class
coupling is needed. In this paper, based on the developed tool called Design
Analyzer we propose a methodology to reuse an existing system with the
objective of enhancing an existing Object oriented system keeping the coupling
as low as possible.Comment: 15 page
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
Recommended from our members
An empirical investigation into contributory factors of change and fault propensity in large-scale commercial object-oriented software
This thesis was submitted for the degree of Doctor of Philosophy and was awarded by Brunel UniversityObject-Oriented design and development dominates both commercial and open source software projects. One of the principal goals of object-oriented design is to aid reuse, and hence, reduce future maintenance efforts of software systems. However, the on-going maintenance of large-scale software systems (both changes and faults) continues to be a significant proportion of the lifecycle of the system and the total investment cost. Understanding and thus being able to predict - or even reduce - the impact of the contributing factors of future maintenance efforts of a software system is thus highly beneficial to software practitioners. In this Thesis we empirically study a large, commercial software system with the principal aim to determine the contributing factors to the change and fault propensity over a three-year period. We consider the object-oriented design context of the software, specifically its inheritance characteristics, coupling and cohesion properties, object-oriented design pattern participation, and size. We also explore the effect of refactoring and test classes in the software. Our results show that several aspects of the design context of a class have an impact to the change and fault-proneness of the software. Specifically, we show that classes with high afferent or efferent coupling are more change and fault-prone; we also identify a number of design patterns whose participants tend to have a higher change and fault propensity than non-participants and we identify a range of inheritance characteristics (in terms of depth of inheritance and number of children) that result in an increase to change and fault-proneness. Furthermore we show that refactoring is a commonly occurring maintenance activity, although it is largely limited to simpler types of refactorings. Finally, we provide some insight into the co-evolution of production and test code during refactoring
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
Analysis of source code metrics from ns-2 and ns-3 network simulators
Ns-2 and its successor ns-3 are discrete-event simulators which are closely related to each
other as they share common background, concepts and similar aims. Ns-3 is still under
development, but it offers some interesting characteristics for developers while ns-2 still
has a large user base. While other studies have compared different network simulators,
focusing on performance measurements, in this paper we adopted a different approach
by focusing on technical characteristics and using software metrics to obtain useful conclusions.
We chose ns-2 and ns-3 for our case study because of the popularity of the former in
research and the increasing use of the latter. This reflects the current situation where ns-3
has emerged as a viable alternative to ns-2 due to its features and design. The paper
assesses the current state of both projects and their respective evolution supported by
the measurements obtained from a broad set of software metrics. By considering other
qualitative characteristics we obtained a summary of technical features of both simulators
including, architectural design, software dependencies or documentation policies.Ministerio de Ciencia e Innovación TEC2009-10639-C04-0
Class movement and re-location: An empirical study of Java inheritance evolution
This is the post-print version of the final paper published in Journal of Systems and Software. The published article is available from the link below. Changes resulting from the publishing process, such as peer review, editing, corrections, structural formatting, and other quality control mechanisms may not be reflected in this document. Changes may have been made to this work since it was submitted for publication. Copyright @ 2009 Elsevier B.V.Inheritance is a fundamental feature of the Object-Oriented (OO) paradigm. It is used to promote extensibility and reuse in OO systems. Understanding how systems evolve, and specifically, trends in the movement and re-location of classes in OO hierarchies can help us understand and predict future maintenance effort. In this paper, we explore how and where new classes were added as well as where existing classes were deleted or moved across inheritance hierarchies from multiple versions of four Java systems. We observed first, that in one of the studied systems the same set of classes was continuously moved across the inheritance hierarchy. Second, in the same system, the most frequent changes were restricted to just one sub-part of the overall system. Third, that a maximum of three levels may be a threshold when using inheritance in a system; beyond this level very little activity was observed, supporting earlier theories that, beyond three levels, complexity becomes overwhelming. We also found evidence of ‘collapsing’ hierarchies to bring classes up to shallower levels. Finally, we found that larger classes and highly coupled classes were more frequently moved than smaller and less coupled classes. Statistical evidence supported the view that larger classes and highly coupled classes were less cohesive than smaller classes and lowly coupled classes and were thus more suitable candidates for being moved (within an hierarchy)
- …