296 research outputs found
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
C to O-O Translation: Beyond the Easy Stuff
Can we reuse some of the huge code-base developed in C to take advantage of
modern programming language features such as type safety, object-orientation,
and contracts? This paper presents a source-to-source translation of C code
into Eiffel, a modern object-oriented programming language, and the supporting
tool C2Eif. The translation is completely automatic and supports the entire C
language (ANSI, as well as many GNU C Compiler extensions, through CIL) as used
in practice, including its usage of native system libraries and inlined
assembly code. Our experiments show that C2Eif can handle C applications and
libraries of significant size (such as vim and libgsl), as well as challenging
benchmarks such as the GCC torture tests. The produced Eiffel code is
functionally equivalent to the original C code, and takes advantage of some of
Eiffel's object-oriented features to produce safe and easy-to-debug
translations
ISA PACKAGER: a Tool for SPL Deployment
In software projects, and particularly in Software Product Line (SPL) projects, product composition and deployment are tasks that are not supported by open source tools. These tasks are repetitive and error-prone. Automation helps on reducing the errors while the productivity increases. in this paper we present a real-world experience through ISA Packager, a generic tool to package and deploy SPLs. in this experience we build a SPL of SCADAs (Supervisory Control and Data Acquisition). Each customized SCADA product evolves in time and ISA Packager is in charge of easing product maintenance and updating
30 Years of Software Refactoring Research: A Systematic Literature Review
Peer Reviewedhttps://deepblue.lib.umich.edu/bitstream/2027.42/155872/4/30YRefactoring.pd
30 Years of Software Refactoring Research:A Systematic Literature Review
Due to the growing complexity of software systems, there has been a dramatic
increase and industry demand for tools and techniques on software refactoring
in the last ten years, defined traditionally as a set of program
transformations intended to improve the system design while preserving the
behavior. Refactoring studies are expanded beyond code-level restructuring to
be applied at different levels (architecture, model, requirements, etc.),
adopted in many domains beyond the object-oriented paradigm (cloud computing,
mobile, web, etc.), used in industrial settings and considered objectives
beyond improving the design to include other non-functional requirements (e.g.,
improve performance, security, etc.). Thus, challenges to be addressed by
refactoring work are, nowadays, beyond code transformation to include, but not
limited to, scheduling the opportune time to carry refactoring, recommendations
of specific refactoring activities, detection of refactoring opportunities, and
testing the correctness of applied refactorings. Therefore, the refactoring
research efforts are fragmented over several research communities, various
domains, and objectives. To structure the field and existing research results,
this paper provides a systematic literature review and analyzes the results of
3183 research papers on refactoring covering the last three decades to offer
the most scalable and comprehensive literature review of existing refactoring
research studies. Based on this survey, we created a taxonomy to classify the
existing research, identified research trends, and highlighted gaps in the
literature and avenues for further research.Comment: 23 page
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
Software reverse engineering education
Software Reverse Engineering (SRE) is the practice of analyzing a software system, either in whole or in part, to extract design and implementation information. A typical SRE scenario would involve a software module that has worked for years and carries several rules of a business in its lines of code. Unfortunately the source code of the application has been lost; what remains is “native ” or “binary ” code. Reverse engineering skills are also used to detect and neutralize viruses and malware as well as to protect intellectual property. It became frighteningly apparent during the Y2K crisis that reverse engineering skills were not commonly held amongst programmers. Since that time, much research has been undertaken to formalize the types of activities that fall into the category of reverse engineering so that these skills can be taught to computer programmers and testers. To help address the lack of software reverse engineering education, several peer-reviewed articles on software reverse engineering, re-engineering, reuse, maintenance, evolution, and security were gathered with the objective of developing relevant, practical exercises for instructional purposes. The research revealed that SRE is fairly well described and most of the related activities fall into one of tw
- …