4,121 research outputs found
Clustering Software Components for Program Restructuring and Component Reuse Using Hybrid XNOR Similarity Function
AbstractComponent based software development has gained a lot of practical importance in the field of software engineering from academic researchers and also from industry perspective. Finding components for efficient software reuse is one of the important problems aimed by researchers. Clustering reduces the search space of components by grouping similar entities together thus ensuring reduced time complexity as it reduces the search time for component retrieval. In this research, we instigate a generalized approach for clustering a given set of documents or software components by defining a similarity function called hybrid XNOR function to find degree of similarity between two document sets or software components. A similarity matrix is obtained for a given set of documents or components by applying hybrid XNOR function. We define and design the algorithm for component or document clustering which has the input as similarity matrix and output being set of clusters. The output is a set of highly cohesive pattern groups or components
Analysis of Software Binaries for Reengineering-Driven Product Line Architecture\^aAn Industrial Case Study
This paper describes a method for the recovering of software architectures
from a set of similar (but unrelated) software products in binary form. One
intention is to drive refactoring into software product lines and combine
architecture recovery with run time binary analysis and existing clustering
methods. Using our runtime binary analysis, we create graphs that capture the
dependencies between different software parts. These are clustered into smaller
component graphs, that group software parts with high interactions into larger
entities. The component graphs serve as a basis for further software product
line work. In this paper, we concentrate on the analysis part of the method and
the graph clustering. We apply the graph clustering method to a real
application in the context of automation / robot configuration software tools.Comment: In Proceedings FMSPLE 2015, arXiv:1504.0301
A method for re-modularising legacy code
This thesis proposes a method for the re-modularisation of legacy COBOL. Legacy code often performs a number of functions that if split, would improve software maintainability. For instance, program comprehension would benefit from a reduction in the size of the code modules. The method aims to identify potential reuse candidates from the functions re-modularised, and to ensure clear interfaces are present between the new modules. Furthermore, functionality is often replicated across applications and so the re-modularisation process can also seek to reduce commonality and hence the overall amount of a company's code requiring maintenance. A 10 step method is devised which assembles a number of new and existing techniques into an approach suitable for use by staff not having significant reengineering experience. Three main approaches are used throughout the method; that is the analysis of the PERFORM structure, the analysis of the data, and the use of graphical representations. Both top-down and bottom-up strategies to program comprehension are incorporated within the method as are automatable, and user controlled processes to reuse candidate selection. Three industrial case studies are used to demonstrate and evaluate the method. The case studies range in size to gain an indication of the scalability of the method. The case studies are used to evaluate the method on a step by step basis; both strong points and deficiencies are identified, as well as potential solutions to the deficiencies. A review is also presented to assesses the three main approaches of the methods; the analysis of the PERFORM and data structures, and the use of graphical representations. The review uses the process of software evolution for its evaluation using successive versions of COBOL software. The method is retrospectively applied to the earliest version and the known changes identified from the following versions are used to evaluate the re-modularisations. Within the evaluation chapters a new link within the dominance tree is proposed as is an approach for dealing with multiple dominance trees. The results show that Ā«ach approach provides an important contribution to the method as well as giving a useful insight (in the form of graphical representations) of the process of software evolution
Legacy Software Restructuring: Analyzing a Concrete Case
Software re-modularization is an old preoccupation of reverse engineering
research. The advantages of a well structured or modularized system are well
known. Yet after so much time and efforts, the field seems unable to come up
with solutions that make a clear difference in practice. Recently, some
researchers started to question whether some basic assumptions of the field
were not overrated. The main one consists in evaluating the
high-cohesion/low-coupling dogma with metrics of unknown relevance. In this
paper, we study a real structuring case (on the Eclipse platform) to try to
better understand if (some) existing metrics would have helped the software
engineers in the task. Results show that the cohesion and coupling metrics used
in the experiment did not behave as expected and would probably not have helped
the maintainers reach there goal. We also measured another possible
restructuring which is to decrease the number of cyclic dependencies between
modules. Again, the results did not meet expectations
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
Feature-based methodology for supporting architecture refactoring and maintenance of long-life software systems
Zusammenfassung
Langlebige Software-Systeme durchlaufen viele bedeutende Veraenderungen im Laufe ihres Lebenszyklus,
um der Weiterentwicklung der Problemdomaenen zu folgen. Normalerweise ist es schwierig eine
Software-Systemarchitektur den schnellen Weiterentwicklungen einer Problemdomaene anzupassen und
mit der Zeit wird der Unterschied zwischen der Problemdomaene und der Software-Systemarchitektur
zu groĆ, um weitere Softwareentwicklung sinnvoll fortzufuehren. Fristgerechte Refactorings der Systemarchitektur
sind notwendig, um dieses Problem zu vermeiden.
Aufgrund des verhaeltnismaeĆig hohen Gefahrenpotenzials und des zeitlich stark verzoegerten Nutzens
von Refactorings, werden diese MaĆnahmen normalerweise bis zum letztmoeglichen Zeitpunkt hinausgeschoben.
In der Regel ist das Management abgeneigt Architektur-Refactorings zu akzeptieren,
auĆer diese sind absolut notwendig. Die bevorzugte Vorgehensweise ist, neue Systemmerkmale ad hoc
hinzuzufuegen und nach dem Motto āAendere nie etwas an einem funktionierenden System!ā vorzugehen.
Letztlich ist das Ergebnis ein Architekturzerfall (Architekturdrift). Die Notwendigkeit kleiner
Refactoring-Schritte fuehrt zur Notwendigkeit des Architektur-Reengineerings. Im Gegensatz zum
Refactoring, das eine normale Entwicklungstaetigkeit darstellt, ist Reengineering eine Form der Software-
āRevolutionā. Reengineeringprojekte sind sehr riskant und kostspielig. Der Nutzen des Reengineerings
ist normalerweise nicht so hoch wie erwartet. Wenn nach dem Reengineering schlieĆlich die erforderlichen
Architekturaenderungen statt.nden, kann dies zu spaet sein. Trotz der enormen in das Projekt
gesteckten Bemuehungen erfuellen die Resultate des Reengineerings normalerweise nicht die Erwartungen.
Es kann passieren, dass sehr bald ein neues, kostspieliges Reengineering erforderlich wird.
In dieser Arbeit werden das Problem der Softwareevolution und der Zerfall von Softwarearchitekturen
behandelt. Eine Methode wird vorgestellt, welche die Softwareentwicklung in ihrer entscheidenden
Phase, dem Architekturrefactoring, unterstuetzt. Die Softwareentwicklung wird sowohl in technischer
als auch organisatorischer Hinsicht unterstuetzt. Diese Arbeit hat neue Techniken entwickelt,
welche die Reverse-Engineering-, Architecture-Recovery- und Architecture-Redesign-Taetigkeiten unterst
uetzen. Sie schlaegt auch Aenderungen des Softwareentwicklungsprozesses vor, die fristgerechte Architekturrefactorings
erzwingen koennen und damit die Notwendigkeit der Durchfuehrung eines Architektur-
Reengineerings vermeiden.
In dieser Arbeit wird die Merkmalmodellierung als Hauptinstrument verwendet. Merkmale werden
genutzt, um die Abstraktionsluecke zwischen den Anforderungen der Problemdomaene und der Systemarchitektur
zu fuellen. Merkmalmodelle werden auch als erster Grundriss fr die Wiederherstellung
der verlorenen Systemarchitektur genutzt. Merkmalbasierte Analysen fuehren zu diversen, nuetzlichen
Hinweisen fuer den erneuten Entwurf (das Re-Design) einer Architektur. SchlieĆlich wird die Merkmalmodellierung
als Kommunikationsmittel zwischen unterschiedlichen Projektbeteiligten (Stakeholdern)
im Verlauf des Softwareengineering-Prozesses verwendet und auf dieser Grundlage wird ein neuer
Anforderungsde.nitionsprozess vorgeschlagen, der die erforderlichen Architekturrefactorings erzwingt.The long-life software systems withstand many significant changes throughout their life-cycle in order
to follow the evolution of the problem domains. Usually, the software system architecture can not
follow the rapid evolution of a problem domain and with time, the diversion of the architecture in
respect to the domain features becomes prohibiting for software evolution. For avoiding this problem,
periodical refactorings of the system architecture are required.
Usually, architecture refactorings are postponed until the very last moment, because of the relatively
high risk involved and the lack of short-term profit. As a rule, the management is unwilling to accept
architecture refactorings unless they become absolutely necessary. The preferred way of working is to
add new system features in an ad-hoc manner and to keep the rule āNever touch a running system!ā.
The final result is an architecture decay. The need of performing small refactoring activities turns into
need for architecture reengineering. In contrast to refactoring, which is a normal evolutionary activity,
reengineering is a kind of software ārevolutionā. Reengineering projects are risky and expensive. The
effectiveness of reengineering is also usually not as high as expected. When finally after reengineering
the required architecture changes take place, it can be too late. Despite the enormous invested efforts,
the results of the reengineering usually do not satisfy the expectations. It might happen that very
soon a new expensive reengineering is required.
This thesis deals with the problem of software evolution and the decay of software architectures.
It presents a method, which assists software evolution in its crucial part, the architecture refactoring.
The assistance is performed for both technical and organizational aspects of the software evolution.
The thesis provides new techniques for supporting reverse engineering, architecture recovery and redesigning
activities. It also proposes changes to the software engineering process, which can force
timely architecture refactorings and thus avoid the need of performing architecture reengineering.
For the work in this thesis feature modeling is utilized as a main asset. Features are used to fill the
abstraction gap between domain requirements and system architecture. Feature models are also used
as an outline for recovering of lost system architectures. Through feature-based analyses a number of
useful hints and clues for architecture redesign are produced. Finally, feature modeling is used as a
communication between different stakeholders of the software engineering process and on this basis a
new requirements engineering process is proposed, which forces the needed architecture refactorings
Design and Analysis of Novel Kernel Measure for Software Fault Localization
The problem of software fault localization may be viewed as an approach for
finding hidden faults or bugs in the existing program codes which are
syntactically correct and give fault free output for some input instances but
fail for all other input instances. Some of the reasons include logical errors,
wrong interpretation of specification, coding errors. Finding such faults is
not possible sometimes with the help of compilers. This is where the necessity
and significance of software fault localization stems out. The main
contribution for this work is to first introduce the block hit-miss function
which relates block vectors of execution sequences of software code over sample
runs performed and the decision vector which denotes fault or error free
output. The similarity measure is applied to the block vector and decision
vectors as input and the pair with maximum similarity is considered as faulty
block.Comment: ICEMIS '15: Proceedings of the The International Conference on
Engineering & MIS 201
Recommended from our members
Improving the build architecture of legacy C/C++ software systems
The build architecture of legacy C/C++ software systems, groups program files in directories to represent logical components. The interfaces of these components are loosely defined by a set of header files that are typically grouped in one common include directory. As legacy systems evolve, these interfaces decay, which contribute to an increase in the build time and the number of conflict in parallel developments. This paper presents an empirical study of the build architecture of large commercial software systems, introduces a restructuring approach, based on Reflexion models and automatic clustering, and reports on a case study using VIM open source editor
- ā¦