Design preservation over subsequent releases of a software product: a case study of Baan ERP

Gurp, Jilles van; Brinkkemper, Sjaak; Bosch, Jan

doi:10.1002/smr.313

Cited by 38 publications

(35 citation statements)

References 17 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Hence, as soon as one of these elements is moved to the subclass, its reference in the superclass is no longer valid, leading to a compiler error. Therefore, these refactorings are all rejected during precondition checking 1 . In this case, our solution is to add new refactorings to the detected refactoring set.…”

Section: B Reification Phase In More Detailmentioning

confidence: 99%

See 1 more Smart Citation

Automated Refactoring Using Design Differencing

Moghadam

Cinnéide

2012

2012 16th European Conference on Software Maintenance and Reengineering

View full text Add to dashboard Cite

Abstract-Software systems that undergo repeated addition of functionality commonly suffer a loss of quality in their underlying designs, termed design erosion. This leads to the maintenance of a system becoming increasingly difficult and time-consuming during its lifetime. Refactoring can reduce the effects of design erosion, but this process requires significant effort on the part of the maintenance programmer. Research into automated refactoring has had some success in reducing the effort involved, however source code refactoring uses refactoring steps that are too small to effect major design changes. Design-level refactoring is also possible, but these approaches operate on design models and do little to help in the subsequent refactoring of the source code.In this paper, we present a novel refactoring approach that refactors a program based both on its desired design and on its source code. The maintenance programmer first creates a desired design (a UML class model) for the software based on the current software design and their understanding of how it may be required to evolve. Then, the source code is refactored using the desired design as a target. This resulting source code has the same behavior as the original, but its design more closely correlates to the desired design.We conducted an investigation using several open source Java applications to determine how precisely it is possible to refactor program source code to a desired design. Our findings were that the original program could be refactored to the desired design with an accuracy of over 90%, hence demonstrating the viability of automated refactoring using design differencing.

show abstract

Section: B Reification Phase In More Detailmentioning

confidence: 99%

“…If the developer ignores the inadequacy of the current design and simply extends the program with the new functionality, the process of design erosion has started. An eroded design results a low quality system in terms of extensibility, flexibility, and maintainability [1].…”

Section: Introductionmentioning

confidence: 99%

Automated Refactoring Using Design Differencing

Moghadam

Cinnéide

2012

2012 16th European Conference on Software Maintenance and Reengineering

View full text Add to dashboard Cite

show abstract

“…Problem Statement: During the long-term maintenance of a software system, it is easy for architectural quality to gradually erode as changes are applied to the design and code [38,25,4,13]. This problem is exacerbated when developers making the changes are unaware [30,12,3]of underlying architectural decisions and their rationales.…”

Section: Active Plumblinementioning

confidence: 99%

“…be slowly eroded by ongoing maintenance activities which are inevitably undertaken to correct faults, improve performance or other quality concerns, and to adapt the system in response to changing requirements [38,22]. Even seemingly innocuous changes made to design or code, can often inadvertently lead to degradation of architectural qualities [13,16].…”

Section: Introductionmentioning

confidence: 99%

A pattern system for tracing architectural concerns

Mirakhorli

Cleland‐Huang

2011

Proceedings of the 18th Conference on Pattern Languages of Programs

View full text Add to dashboard Cite

A software architecture is carefully designed to satisfy the quality concerns of its stakeholders, and as such, represents a systematic and intricately balanced set of design decisions which deliver required qualities such as performance, reliability, and safety. In practice, architectural degradation tends to occur over the lifetime of the software system, as developers make ongoing and incremental maintenance changes to the system without knowledge of its underlying design decisions. Fortunately, this problem can be alleviated by establishing traceability between concrete elements in the architecture and their associated design decisions, and then using these traceability links to keep developers informed of relevant architectural tactics, styles, and design patterns throughout the development process. This paper focuses on the task of creating and using such traceability links. We present six trace creation patterns describing techniques and supporting structures for creating architecturally significant traceability links, and two usage patterns describing techniques for using the created links to help preserve qualities in the architectural design. The patterns described in this paper emerged from our experiences and observations of tracing architectural concerns in safety critical systems.

show abstract

“…They suggested that decayed architectures make their systems more prone to defects [14] and that, in some not-so-rare cases, a system architecture and its implementation code must be thrown away because it is too hard to maintain, unless the decay can be stopped before the architecture is completely unworkable [15].…”

Section: Introductionmentioning

confidence: 99%

ADvISE: Architectural Decay in Software Evolution

Hassaine

Guéhéneuc

Hamel

et al. 2012

2012 16th European Conference on Software Maintenance and Reengineering

View full text Add to dashboard Cite

Abstract-Software systems evolve continuously, requiring continuous maintenance and development. Consequently, their architecture tends to degrade with time as it becomes less relevant to new, emerging requirements. Therefore, stability or resilience is a primary criterion for evaluating an architecture. In this paper, we propose a quantitative approach to study the evolution of the architecture of object oriented systems over time. In particular, we represent an architecture as a set of triplets (S, R, T ), where S and T represent two classes and R is a relationship linking them. We use these triplets as basic unit to measure the stability of an architecture. We show the applicability and usefulness of our approach by studying the evolution of three open source systems: JFreeChart and Xerces-J and Rhino.

show abstract

Design preservation over subsequent releases of a software product: a case study of Baan ERP

Cited by 38 publications

References 17 publications

Automated Refactoring Using Design Differencing

Automated Refactoring Using Design Differencing

A pattern system for tracing architectural concerns

ADvISE: Architectural Decay in Software Evolution

Contact Info

Product

Resources

About