bluuebunny/crossref_metadata_2025_split huggingface dataset:
A model for assembly program maintenance
Authors: Chen S. , Heisler K. G. , Tsai W. T. , Chen X. , Leung E. 
Published: November 2006

AbstractThis paper presents a model for understanding assembly programs for software maintenance. It is based on the theory that explicit representation of various structural and functional elements of code and multiple relationships among them will aid program understanding and thus software maintenance. We present a parsing technique to extract all the required elements from assembly code to populate the model. The model is a reverse engineering technique. We use the term reverse engineering in its broad sense to include specification as well as design recovery. Most features of this model have been implemented in a tool named “RETA” for Reverse Engineering Tool for Assembly programs.The model is useful for software maintenance activities such as program understanding, ripple effect analysis, and program re‐documentation. The ripple effect of a contemplated change is the parts of code that depend on the variable or a piece of code to be changed. Once the change is made, those parts need to be re‐examined for possible modification. The model generates a functional menu for a given application. The menu describes the functionality of each routine. It is a hierarchical presentation of major program routines, the sub‐routines supporting each major routine and so on. A routine at any level of detail consists of one or more paths through the code. Paths are presented as control flow sequences between code blocks. Code blocks, and hence functionalities, use and modify data.The maintainer locates the routine to be modified at the lowest level of detail within the functional menu. This automatically slices out the set of paths, and hence the set of code blocks, that have a role in the functionality to be changed. The code blocks in the slice determine the data that are used and modified within the routine to be changed. Path analysis and associated data‐used and data‐modified information are used to determine which code blocks are to be changed and which data roles are to be modified. The same set of relations are applied in reverse to identify the ripple effect.
Modelling and maintenance software systems at the teleological level
Authors: Karakostas V. 
Published: November 2006

AbstractSoftware maintenance is necessitated to a large extent by changing user requirements. However, the relationship between the user requirements and the implemented software system is not made explicit in current development approaches, making the mapping of changing requirements to corresponding maintenance activities difficult. The teleological approach advocates the construction of a model which links the components of a software system to the concepts of the application domain which they implement, i.e to user requirements. Subsequently, the teleological model is used for simulating the actual maintenance activities, as they are triggered by the changing requirements, and for identifying their nature and estimating their cost.
Producing better maintainable JSD specifications by grouping common aspects
Authors: Borgers M. , Munro M. 
Published: November 2006

AbstractThe Jackson methodology for systems development is seen as a formal methodology. Although it is formal, the analyst has a freedom to specify models of problems in alternative ways without giving any indication which one is the better. Proposals to extend the methodology with the concepts ‘(near) static entity’ and ‘static roles’ give the analyst even more freedom than before. From the maintenance point of view this can lead to problems of understandability of the models. Also some enhancements cannot be done without completely redesigning entities. In this paper we propose to separate the existence aspect of an entity in one process. A second proposal is to model relationships (i.e. aspects comon to two or more entities) between entities explicitly using entity‐relationship notation. In this way, more maintainable specifications will be obtained.
Enhancements through design transformations: A retroactive case study
Authors: Rotenstreich Shmuel 
Published: November 2006

AbstractA formal approach to software design in the form of transformations is shown to be useful for the redesign of existing systems. A design transformation maps a given design into an alternative design. Transformations are based on a model that consists of program blocks and the input and output data of these blocks. The result of a transformation may be a rearrangement of the blocks, splitting of blocks or a combination of existing blocks. Typically, software design concepts are applicable to designs that stem from specifications, they are less capable when applied to existing systems. A transformational scheme is inherently iterative. The redesign of existing systems is, therefore, the application of transformations starting from an iteration that happens to be the existing system. A real‐life example, in which a function in a distributed system was first designed and then redesigned, both intuitively, is the basis of the case study. We show that the redesign process that was undertaken in order to enhance a function can be achieved with the design transformations proposed. Through the example, we demonstrate that the transformational scheme is not difficult to apply, precise, and capable of reusing program components not affected by the redesign.
Insights into testing and regression testing global variables
Authors: Leung Hareton K. N. , White Lee 
Published: November 2006

AbstractDespite the existence of global variables in many software systems, testing global variables has traditionally been overlooked by the testing community. This state of the practice leads to the release of some software systems with untested properties. In this paper, we present some insights into the problem of testing and regression testing global variables. A basis set of testing problems for parameters will be identified and the testing problem of global variables will be mapped onto a combination of these basis cases. It will be shown that global variables can be treated as parameters and can be tested accordingly. Testing strategies and regression testing strategies for unit, integration, and system testing global variables are described.
Measures for maintenance management: A case study
Authors: Neil Martin , Cole Robert J. , Slater David 
Published: November 2006

AbstractSoftware maintenance is an important activity, but is often perceived as less challenging than software development. By following a management‐led discipline of data collection and reporting, maintenance control and visibility can be achieved. The discipline aims to promote the maintenance function within an organization and show that it is as demanding as software development.This paper describes a maintenance data collection scheme (MDCS) which was implemented at an industrial site, as a case study. This implementation resulted in: an increase in management control, promotion of maintenance to senior management, systematic recording of faults, and the successful application of a statistical model to the weekly number of maintenance incidents. An incident form was developed to record data on the effort necessary to resolve incidents, the elapsed time, status, category and severity of incidents. It turned out that maintenance incident effort was highly variable. Maintenance reports were prepared for management based on the results of data analysis. These reports addressed the following questions: Is the maintenance effort increasing or decreasing? How fast are maintenance problems being dealt with? Which systems are demanding the most effort? Statistical techniques were used to model maintenance activities. Multivariate techniques were found to be inappropriate for the type of data collected. A log‐normal distribution was fitted to the weekly number of maintenance incidents. This distribution gave a confidence interval of practical use for management.
Creating specifications from code: Reverse‐engineering techniques
Authors: Breuer P. T. , Lano K. 
Published: November 2006

AbstractReverse‐engineering application codes back to the design and specification stage may entail the recreation of lost information for an application, or the extraction of new information.We describe techniques which produce abstractions in object‐oriented and functional notations, thus aiding the comprehension of the essential structure and operations of the application, and providing formal design information which may make the code much more maintainable and certainly more respectable.The two types of application considered here are (1) data processing applications written in COBOL — of primary importance owing to their predominance in present computing practice — and (2) scientific applications written in FORTRAN. These two require somewhat different abstraction approaches.
A formal approach to perfective software maintenance: Integration using a basis
Authors: Rine David 
Published: November 2006

AbstractWe investigate how a formalism, common to many areas of applied mathematics and engineering, known as a basis can be applied to perfective maintenance and integration in software engineering, using an object‐oriented approach. It is concluded that this formalism serves as a mathematical model for perfective software maintenance and integration activities. Theorems and properties about the model are reported as guides to software maintenance. The model and formal maintenance techniques have been applied to a software system in the management information systems area to demonstrate this approach to perfective maintenance and to assist in validating the model.
Software Maintenance: 1990 status
Authors: Dekleva Sasa M. 
Published: November 2006

AbstractResults of a survey of the 1990 Software Maintenance Association Meeting and Conference attendees indicate a number of changes in software maintenance‐related issues. Systems are ageing and growing in size. Software maintenance is separated from new systems development in more than half of the organizations. Over 45% of maintenance work is spent on functional enhancements. About three out of four organizations depend on specific individuals because no‐one else can maintain particular systems and only 5% of organizations employ a formal method for determining when software should be rewritten. Responses describing major problems and preferred changes in DP organizations were classified into general categories and compared with previous similar studies. Trends show maturation of software maintenance toward a greater appreciation of maintenance and at least an intention of managers to improve the support of this activity.
From programs to object code and back again using logic programming: Compilation and decompilation
Authors: Bowen Jonathan 
Published: November 2006

AbstractA compiler may be specified by a description of how each construct of the source language is translated into a sequence of object code instructions. It is possible to produce a compiler prototype almost directly from this specification in the form of a logic program. This defines a relation between allowed high‐level and low‐level program constructs. Normally a high‐level program is supplied as input to a compiler and object code is returned. Because of the declarative nature of a logic program, it is possible for the object code to be supplied and the allowed high‐level programs returned, resulting in a decompiler, provided enough information is available in the object code. This paper discusses the problems of adopting such an approach in practice. A simple compiler and decompiler are presented in full as an example in the logic programming language Prolog, together with some sample output. The possible benefits of usingconstraint logic programmingare also considered. Potential applications include reverse‐engineering in the software maintenance process, verification of safety‐critical object code, quality assessment of code and program debugging tools.
RE2: Reverse‐engineering and reuse re‐engineering
Authors: Canfora G. , Cimitile A. , Munro M. 
Published: November 2006

AbstractInitial research in reuse was in the designing and implementation of reusable software. This research, although fruitful, did not address the area of extracting reusable components from existing software. In this paper the term reuse is used to mean the ‘reuse of existing source code’. A process called ‘reuse re‐engineering’ is defined and this, together with techniques from reverse‐engineering, form a new method for achieving reuse. A reference paradigm is established to implement the reuse re‐engineering process. This process is divided into five sequential phases, each characterized by the objects it produces. These phases are: candidature, election, qualification, classification and storage, and search and display. This paper concentrates on the first three phases because they produce reusable modules from existing systems. In selecting candidates for reuse, different abstractions have to be applied, namely functional abstraction (algorithms) and data abstractions (data structures and data types). This paper presents a formalized approach to each of these abstractions. The approach proposed in this paper aims to promote reuse in industrial software production environments.
Reusability in software maintenance: A Japan—USA comparison
Authors: Pei Gary , Victoria Agustina 
Published: November 2006

AbstractJapan benefits from a level of software reuse in software maintenance more than ten times the level in the USA. We report in this paper on our investigation during 1992 and 1993 into the management factors associated with that difference. The four main parts of this paper are the motivation for applying software reusability, maintenance management in the USA, maintenance management in Japan, and USA versus Japan. Our investigation included on‐site visits in Japan and the USA, interviews with experts in Japan and the USA, and a review of the relevant Japanese and American literature (one of us speaks and reads Japanese fluently).Organizations in Japan applying software reuse report reduced maintenance backlogs, better satisfaction of customer (user) requests, and improved maintenance productivity. In Japan, about a third of organizations apply software reuse, and the reuse level typically is in the 50% to 75% range, we observe. In the USA, less than 2% of organizations apply software reuse in software maintenance, and the reuse level those organizations achieve typically is below 35%. The approach to software reuse in Japan is more business‐oriented, with an emphasis on team work‐methods and quality improvement. The approach in the USA is more technically oriented, with an emphasis on tools and operating practices. The approach in Japan reflects a tradition of building and maintaining in terms of assemblies and subassemblies to help control product quality over a long term. The approach in the USA reflects managements' pressure for a short‐term payoff, and the relatively easy availability of personnel skills when needed. In both Japan and the USA, personnel factors are a major concern for information systems management in determining the extent of software reuse in software maintenance. Underlying all software maintenance reuse differences between Japan and the USA are structural and cultural differences which shape the extent and manner of applying software reusability in software maintenance.
A new approach to finding objects in programs
Authors: Livadas Panos E. , Johnson Theodore 
Published: November 2006

AbstractSoftware maintenance is difficult and costly because the maintainer must understand the existing relationships in the maintained code. The maintainer's job can be made considerably easier if the objects in the code (related groups of types, data, and procedures) are identified. In this paper, we discuss methods for identifying objects in programs, and present a new approach that relies on these key features. First, our internal program representation (IPR) lets us make a more precise identification of objects than previous methods allowed. Second, we introduce the idea of receiver‐based object identification. Third, we introduce the idea of two‐step object identification, which gives the user greater control in precisely identifying objects. Our object finding tool can be used with the other tools our IPR provides to create an integrated software maintenance environment.
Cooperative work in large‐scale software systems
Authors: Belkhatir Noureddine , Estublier Jacky , Melo Walcélio L. 
Published: November 2006

AbstractSoftware maintenance is responsible for approximately 80% of the total cost of software. In order to reduce maintenance costs by improving both software productivity and quality, several software engineering environments have been built. In this paper, we present the main characteristics of Adele system, showing how this system is able to take account of software maintenance problems. We concentrate on the ability of this system to accept the specification of project‐specific policies and how these policies can be enforced automatically. We illustrate this with examples which with software maintenance. The second example is presented in the annexe and shows an example of cooperative work in an aerospace company. We conclude this article by presenting the lessons learned using our approach and our projects for the future.
Decision‐driven Maintenance
Authors: Lanubile Filippo , Visaggio Giuseppe 
Published: November 2006

AbstractThis paper presents our approach to design recording which aims to facilitate the impact analysis of changes in data, functions, or the external environment. A whole software system is represented as a web which integrates the different work products of the software life cycle and their mutual relationships. A traceability relationship associates the objects with each other so that impact analysis can be performed. Internal traceability is provided by semantic links between software objects representing the work products of a development phase, while external traceability is assured by the cognitive links between software objects from different phases. System understanding is supported by the decisions which are involved in the transformation process. The history of these decisions is retained over time so that previous decisions can be examined for maintenance and reuse activities. The approach has been implemented through a Traceability Support System, a maintenance tool which combines the characteristics of program abstractors, project databases and design rationale capture tools. The approach and the tool also both support traceability in heterogeneous systems, which have subsystems implemented on different platforms. Finally, analysis is made of the results of an empirical investigation carried out to assess the approach.
An empirical study of maintenance activities in two object‐oriented systems
Authors: Li Wei , Henry Sallie 
Published: November 2006

AbstractDecades of research on maintenance activities in the procedural paradigm has produced several conclusions. Among these conclusions are recommendations that a reduction in maintenance cost could be achieved by a more controlled design process, and by more rigorous testing of potential problem areas earlier in the life‐cycle. With the increased emphasis on the object‐oriented paradigm, the authors performed an empirical study of the maintenance patterns in two commercial object‐oriented systems. Although this is a preliminary study, intuition is presented as insight into the object‐oriented maintenance activities.
Formal methods for legacy systems
Authors: Ward M. P. , Bennett K. H. 
Published: November 2006

AbstractA method is described for obtaining useful information from legacy code. The approach uses formal proven program transformations, which preserve or refine the semantics of a construct while changing its form. The applicability of a transformation in a particular syntactic context is checked before application. By using an appropriate sequence of transformations, the extracted representation is guaranteed to be equivalent to the code. In this paper, we focus on the results of using this approach in the reverse‐engineering of medium‐scale, industrial software, written mostly in languages such as assembler and JOVIAL. Results from both benchmark algorithms and heavily modified, geriatric software are summarized. It is concluded that the approach is viable, for self‐contained code, and that useful design information may be extracted from legacy systems at economic cost. We conclude that formal methods have an important practical role in the reverse‐engineering process.
Improving reverse‐engineering through the use of multiple knowledge sources
Authors: Layzell P. J. , Freeman M. J. , Benedusi P. 
Published: November 2006

AbstractWith the growing awareness of the importance of software maintenance has come a re‐evaluation of software maintenance tools. Such tools range from source code analysers to semi‐intelligent tools which seek to reconstruct system designs and specification documents from source code. However, it is clear that relying solely upon source code as a basis for reverse‐engineering has many problems. These problems include poor abstraction, which leads to over‐detailed specification models and the inability to link other parts of a software system, such as documentation and user expertise, to the underlying code.This paper describes the work of the Esprit DOCKET project which has developed a prototype environment to support the development of a system model linking user‐oriented, business aspects of a system, to operational code using a variety of knowledge source inputs: code, documents and user expertise. The aim is to provide a coherent model to form the basis for system understanding and to support the software change and evolution process.
Software maintenance—an industrial experience
Authors: Onoma A. K. , Tsai W. T. , Tsunoda F. , Suganuma H. , Subramanian S. 
Published: November 2006

AbstractThis paper gives an overview of the software maintenance process of Hitachi Software Engineering (HSK) Co., Ltd in Japan‐including its success and failure cases. It discusses HSK's software processes, issues, use of specific tools and techniques such as IMOZU diagrams, and approaches in solving problems. These include the requirement capturing process, reverse‐engineering techniques, environmental changes, change management, and project management. By discussing actual project experiences, we point to certain lessons and their implications for research in software maintenance. We also present the latest re‐engineering CASE tools, such as RE‐ENGINEERING and SEWB3, used at HSK.
Understanding software through numbers: A metric based approach to program comprehension
Authors: Sneed Harry M. 
Published: November 2006

AbstractThere are many approaches to try to comprehend software. Code can be statically analysed and its structure and content displayed as lists, tables or graphs. Most of the literature on software comprehension deals with this approach. Code can also be dynamically executed and its reaction to impulses from outside registered and documented. This is a useful approach to understanding object‐orientated systems. A third approach is not to deal with the code at all, but instead to extract information from existing documents and to combine it into a whole. The problem here is that important documents are often missing and those that are available are out of date. A fourth approach is to interview the experts and to aggregate their views of the software, how it is composed and how it functions as opposed to how it should be composed and how it should function. All of these approaches have been examined and reported on by the participants of the ESPRIT DOCKET Project (1992).A fifth approach to software understanding, the one to be presented here, is that of comprehension through numbers by software managers, i.e. using metrics to support the decision making process.