Figure 2 - uploaded by Christelle Urtado
Content may be subject to copyright.
Source publication
Software architectures are subject to several types of change during the software lifecycle (e.g. adding requirements, correcting bugs, enhancing performance). The variety of these changes makes architecture evolution management complex because all architecture descriptions must remain consistent after change. To do so, whatever part of the archite...
Citations
... However, a series of changes applied to software system may alter its architecture or structure, leading to several inconsistencies. These lead to component typemismatch in software development and we cannot easily add/delete the desired component at runtime [22]. To reduce these inconsistencies and enhance reliability, evolution must be handled at entire software life cycle steps. ...
... In [22,38], the authors proposed and implemented the automated management of component-based architecture evolution across various levels of abstraction. The main focus of this paper is to ensure consistent and coherent architecture throughout the component based software development lifecycle. ...
Changes are inevitable in software due to technology advancements, and changes in business requirements. Making changes in the software by insertion, deletion or modification of new code may lead to malfunctioning of the old code. Hence, there is a need for a priori analysis to ensure and capture these types of changes to run the software smoothly. Making changes in the software while it is in use is called dynamic evolution. Due to the lack of formal modeling and verification, this dynamic evolution process of software systems has not become prominent. Hence, we used the bigraphical reactive system (BRS) technique to ensure that changes do not break the software functionality (adversely affect the system). BRS provides a powerful framework for modeling, analyzing, and verifying the dynamic evolution of software systems, resulting in ensuring the reliability and correctness of evolving software system. In this paper, we proposed a formal method technique for modeling and verifying the dynamic evolution process (changing user requirements at run time) using the BRS. We used a bigraph to model software architectures and described the evolution rules for supporting the dynamic changes of the software system. Finally, we have used the BigMC model checker tool to validate this model with its properties and provide associated verification procedures.
... However, none of these works address functional requirements in their design refactoring approaches. As the planning evolution process is a challenging task, some techniques [21] [22] [23] [24] have been provided. Although these techniques can well support planning the evolution of software, they focused more on organising changes at the implementation level. ...
... However, their approach requires defining a customised algorithm specific to the pattern. Mokni et al. [22] proposed formal specification of architectural design to generate evolution plans. With a formal specification, the change requests can be analysed to generate the evolution plan. ...
... The management of evolution process usually tracks and manages the change of software elements and the change among elements through application software configuration management model and other corresponding tools. For example, an evolution management model which can support multi-layer software architecture and track the changes of software in specification, implementation and deployment was designed [3]. Zhong combined the definition of version information with component model and software configuration management model, and proposed a component model which can support component-based software evolution to realize the evolution management of component-based software [4]. ...
... Experiments show that when the similarity thresholds are smaller, the edit distances between the evolutionary binary trees of composite components and that of real system versions are shorter, that is to say, the two kind of trees are becoming more similar. The reasons may be that: (1) in our experiments, the amount of system versions are insufficient; (2) in reality, the evolutionary binary tree of a real system version looks similar as a tree with a single branch in structure because software system is generally updated on the basis of the previous system version; (3) the multi-dimensional attributes selected as measurement indicators are not representative when measure the similarity of component versions. ...
In the process of software evolution, a lot of evolution history information will be stored in software repository. Because some open source repositories (such as GitHub) only record the version of every source file, it is difficult for people to comprehend and manage the evolution of software component and software architecture. In the paper, we propose the concept of software evolutionary binary tree to present the evolution history of software architecture and its components, propose a method to recover them by software architecture recovery technology as well. The experimental results of four open source software (Cassandra, Hbase, Hive and Openjpa) demonstrate that the method is effective.
... Automated approaches have been proposed to refactor existing designs [2,26,43] and to plan architectural migration [25,31,37,40]. Some approaches focus on planning the evolution of software architectural design, such as [7,14,31,33]. We have found limitations in the existing work as follows. ...
... Formal techniques have been applied to evolution planning. For example, in the approach proposed by Mokni et al. [33], formal specification of architectural design has been used to generate evolution plans. With a formal specification, we can analyse the change requests to generate the evolution plan and ensure that architecture inconsistencies do not occur. ...
Software architectural designs are usually changed over time to support emerging technologies and to adhere to new principles. Architectural migration is an important activity that helps to transform the architectural styles applied during a system’s design with the result of modernising the system. If not performed correctly, this process could lead to potential system failures. This article presents an automated approach to refactoring architectural design and to planning the evolution process. With our solution, the architectural design can be refactored, ensuring that system functionality is preserved. Furthermore, the architectural migration process allows the system to be safely and incrementally transformed. We have evaluated our approach with five real-world software applications. The results prove the effectiveness of our approach and identify factors that impact the performance of architectural verification and migration planning. An interesting finding is that planning algorithms generate migration plans that differ in term of their relative efficiency.
... Software Composition Analysis (SCA) [45], [46] refers to the process that provides visibility of open source components in a system. As stated by developer #14, "Managing a product against software decay can be a nightmare, but again a good SCA tool should be able to take care of that. ...
As software systems evolve, their architecture is meant to adapt accordingly by following the changes in requirements, the environment, and the implementation. However, in practice, the evolving system often deviates from the architecture, causing severe consequences to system maintenance and evolution. This phenomenon of architecture erosion has been studied extensively in research, but not yet been examined from the point of view of developers. In this exploratory study, we look into how developers perceive the notion of architecture erosion, its causes and consequences, as well as tools and practices to identify and control architecture erosion. To this end, we searched through several popular online developer communities for collecting data of discussions related to architecture erosion. Besides, we identified developers involved in these discussions and conducted a survey with 10 participants and held interviews with 4 participants. Our findings show that: (1) developers either focus on the structural manifestation of architecture erosion or on its effect on run-time qualities, maintenance and evolution; (2) alongside technical factors, architecture erosion is caused to a large extent by non-technical factors; (3) despite the lack of dedicated tools for detecting architecture erosion, developers usually identify erosion through a number of symptoms; and (4) there are effective measures that can help to alleviate the impact of architecture erosion.
... Software Composition Analysis (SCA) [45], [46] refers to the process that provides visibility of open source components in a system. As stated by developer #14, "Managing a product against software decay can be a nightmare, but again a good SCA tool should be able to take care of that. ...
As software systems evolve, their architecture is meant to adapt accordingly by following the changes in requirements, the environment, and the implementation. However, in practice, the evolving system often deviates from the architecture, causing severe consequences to system maintenance and evolution. This phenomenon of architecture erosion has been studied extensively in research, but not yet been examined from the point of view of developers. In this exploratory study, we look into how developers perceive the notion of architecture erosion, its causes and consequences, as well as tools and practices to identify and control architecture erosion. To this end, we searched through several popular online developer communities for collecting data of discussions related to architecture erosion. Besides, we identified developers involved in these discussions and conducted a survey with 10 participants and held interviews with 4 participants. Our findings show that: (1) developers either focus on the structural manifestation of architecture erosion or on its effect on run-time qualities, maintenance and evolution; (2) alongside technical factors, architecture erosion is caused to a large extent by non-technical factors; (3) despite the lack of dedicated tools for detecting architecture erosion, developers usually identify erosion through a number of symptoms; and (4) there are effective measures that can help to alleviate the impact of architecture erosion.
... However, this approach is based on user feedback that can be biased. Mokni et al. [13] presented B formal specification of architecture design to generate evolution plan. The change request can be analysed before the evolution plan is generated and ensured that architecture inconsistencies do not occur. ...
... This is why this thesis proposes an approach to re-document software architectures from raw source code. This approach is based on Dedal [Zha+12b; Mok+16a], which provides three architecture levels for tracking main steps of software life-cycle. Moreover, it also provides a formalized basis for calculating automated evolution plan. ...
... Mokni et al. [Mok+16a] address automatic evolution in Dedal using formal rules based type theory. They introduce a way for performing architecture analysis and automatic architecture consistency recovery at three abstraction levels. ...
... Mok+16a], which provides a strong theoretical basis for analyzing component type hierarchies. The particularity of this approach is that it actually re-documents the software life-cycle. ...
All along its life-cycle, a software may be subject to numerous changes that may affect its coherence with its original documentation. Moreover, despite the general agreement that up-to-date documentation is a great help to record design decisions all along the software life-cycle, software documentation is often outdated. Architecture models are one of the major documentation pieces. Ensuring coherence between them and other models of the software (including code) during software evolution (co-evolution) is a strong asset to software quality. Additionally, understanding a software architecture is highly valuable in terms of reuse, evolution and maintenance capabilities. For that reason, re-documenting software becomes essential for easing the understanding of software architectures. However architectures are rarely available and many research works aim at automatically recovering software architectures from code. Yet, most of the existing re-documenting approaches do not perform a strict reverse-documenting process to re-document architectures "as they are implemented" and perform re-engineering by clustering code into new components. Thus, this thesis proposes a framework for re-documentating architectures as they have been designed and implemented to provide a support for analyzing architectural decisions. This re-documentation is performed from the analysis of both object-oriented code and project deployment descriptors. The re-documentation process targets the Dedal architecture language which is especially tailored for managing and driving software evolution.Another highly important aspect of software documentation relates to the way concepts are versioned. Indeed, in many approaches and actual version control systems such as Github, files are versioned in an agnostic manner. This way of versioning keeps track of any file history. However, no information can be provided on the nature of the new version, and especially regarding software backward-compatibility with previous versions. This thesis thus proposes a formal way to version software architectures, based on the use of the Dedal architecture description language which provides a set of formal properties. It enables to automatically analyze versions in terms of substitutability, version propagation and proposes an automatic way for incrementing version tags so that their semantics corrrespond to actual evolution impact. By proposing such a formal approach, this thesis intends to prevent software drift and erosion.This thesis also proposes an empirical study based on both re-documenting and versioning processes on numerous versions on an enterprise project taken from Github.
... Architecture models are used in nearly all steps of the software lifecycle, from its early design, as an abstract, ideal solution to meet users requirements, to its actual deployment and execution. Academic research has proposed many architecture description languages (ADLs) to support architecture conceptual design [11] whereas industry has proposed frameworks for runtime architecture deployment and management [4]. The ideal technology should both be flexible and easy to use for software developers and help document the architecture, increase component reusability and maintainability and manage change for software architects. ...
Software architecture modeling plays a key role in software development and, beyond, in software quality. The Spring framework is widely used in industry to deploy software. This paper evaluates whether Spring fosters good practices for architecture definition. It describes the results of an empirical study, based on a corpus of open-source Spring projects. Analysis shows that a strong (70%) majority of projects mixes all Spring architecture definition features. This can be considered as a pragmatic use of a very flexible tool. However, few good practice documentation and tool assistance exist to prevent hazardous architecture constructions. The paper highlights these situations and concludes on recommendations to assist developers.
... Moreover, it is important to represent the software at three abstraction levels in order to trace design decisions through the whole development process. To do so, we use the Dedal [12], [8] architecture description language (ADL) developed by our team. This paper proposes to reconstruct component-based architectures from Java Spring [6] projects. ...
... A. Dedal, a Three-Level Architecture Description Language Dedal [12], [8] is a three-level architecture description language (ADL) designed to give a representation of the entire life cycle of architectures and a support to manage their evolution. Design is represented by the Specification level which is composed of abstract component types. ...
... Following this taxonomy, the goals of the discussed approach are twofold. The first goal is to improve component reuse, by extracting component-based architecture descriptions, such as MAP [10], PuLSE / SAVE [7] and ROMANTIC [1], [9] approaches, but targeting the Dedal [12], [8] ADL. The second goal is to provide the foundations for managing conformance checking (Bauhaus [4], [2], DiscoTect [11], PuLSE / SAVE [7]), evolution, co-evolution (PuLSE / SAVE [7], Huang et al. [5]) and maintenance using the formal rules that have previously [8] been defined in Dedal. ...
