Fig 3 - uploaded by Tom Mens
Content may be subject to copyright.
9: Fractal Figures applied to the network/protocol hierarchy of Mozilla. The size metric maps the number of bug reports.
Source publication
![Fig. 2.5: Polymetric view adapted from [442]](profile/Tom-Mens/publication/220092918/figure/fig1/AS:669068860338188@1536529855737/Polymetric-view-adapted-from-442_Q320.jpg)
![Fig. 2.7: Arc diagram adapted from [541]](profile/Tom-Mens/publication/220092918/figure/fig3/AS:669068860325901@1536529855783/Arc-diagram-adapted-from-541_Q320.jpg)
![Fig. 2.8: Clones visualiser view in Eclipse adapted from [494]](profile/Tom-Mens/publication/220092918/figure/fig4/AS:669068860325902@1536529855813/Clones-visualiser-view-in-Eclipse-adapted-from-494_Q320.jpg)
Evolving and maintaining software-intensive systems is critical, and, consequently, most developers are involved in maintaining, incrementally enhancing, and adapting existing systems. Many research groups are working in this research area of software evolution and producing a growing body of knowledge. This special issue brings the topic into the...
Citations
... This knowledge is useful for supporting decision-making in development teams with little time for delivering features. Indeed, there might be hundreds of stakeholders' demands for developers to worry about while performing software evolution [24]. Thus, they may find certain critical attributes worth managing in the detriment of other critical attributes. ...
Several refactorings performed while evolving software features aim to improve internal quality attributes like cohesion and complexity. Indeed, internal attributes can become critical if their measurements assume anomalous values. Yet, current knowledge is scarce on how developers perceive the relevance of critical internal attributes while evolving features. This qualitative study investigates the developers' perception of the relevance of critical internal attributes when evolving features. We target six class-level critical attributes: low cohesion, high complexity, high coupling, large hierarchy depth, large hierarchy breadth, and large size. We performed two industrial case studies based on online focus group sessions. Developers discussed how much (and why) critical attributes are relevant when adding or enhancing features. We assessed the relevance of critical attributes individually and relatively, the reasons behind the relevance of each critical attribute, and the interrelations of critical attributes. Low cohesion and high complexity were perceived as very relevant because they often make evolving features hard while tracking failures and adding features. The other critical attributes were perceived as less relevant when reusing code or adopting design patterns. An example of perceived interrelation is high complexity leading to high coupling. Index Terms-internal quality attribute, refactoring, software feature, software evolution, industry case study
... This knowledge is useful for supporting decision-making in development teams with little time for delivering features. Indeed, there might be hundreds of stakeholders' demands for developers to worry about while performing software evolution [24]. Thus, they may find certain critical attributes worth managing in the detriment of other critical attributes. ...
Several refactorings performed while evolving software features aim to improve internal quality attributes like cohesion and complexity. Indeed, internal attributes can become critical if their measurements assume anomalous values. Yet, current knowledge is scarce on how developers perceive the relevance of critical internal attributes while evolving features. This qualitative study investigates the developers' perception of the relevance of critical internal attributes when evolving features. We target six class-level critical attributes: low cohesion, high complexity, high coupling, large hierarchy depth, large hierarchy breadth, and large size. We performed two industrial case studies based on online focus group sessions. Developers discussed how much (and why) critical attributes are relevant when adding or enhancing features. We assessed the relevance of critical attributes individually and relatively, the reasons behind the relevance of each critical attribute, and the interrelations of critical attributes. Low cohesion and high complexity were perceived as very relevant because they often make evolving features hard while tracking failures and adding features. The other critical attributes were perceived as less relevant when reusing code or adopting design patterns. An example of perceived interrelation is high complexity leading to high coupling.
... Traditional software engineering focuses on principles for developing high-quality software systems and maintaining the systems as they evolve in real-world environments (Mens et al. 2010;Edan and Pliskin 2001). Software that does not evolve during its lifetime, however, will not be able to keep up with changing requirements and will become outdated over time. ...
... Software that does not evolve during its lifetime, however, will not be able to keep up with changing requirements and will become outdated over time. This has profound implications for existing software process models, which must respond to the increasing need for change and evolution by introducing iterative, incremental, and evolutionary approaches (Mens et al. 2010;Boehm and Turner 2005;Beck et al. 2001). In demonstration, software maintenance and evolution have emerged in the last decade as key research fields that explicitly differentiate between the time phases before, during, and after the software is delivered: denoted development time, deployment time, and runtime, respectively (Jacobson et al. 1999). ...
Smart contracts are seen as the major building blocks for future autonomous blockchain- and Distributed Ledger Technology (DLT)-based applications. Engineering such contracts for trustless, append-only, and decentralized digital ledgers allows mutually distrustful parties to transform legal requirements into immutable and formalized rules. Previous experience shows this to be a challenging task due to demanding socio-technical ecosystems and the specificities of decentralized ledger technology. In this paper, we therefore develop an integrated process model for engineering DLT-based smart contracts that accounts for the specificities of DLT. This model was iteratively refined with the support of industry experts. The model explicitly accounts for the immutability of the trustless, append-only, and decentralized DLT ecosystem, and thereby overcomes certain limitations of traditional software engineering process models. More specifically, it consists of five successive and closely intertwined phases: conceptualization, implementation, approval, execution, and finalization. For each phase, the respective activities, roles, and artifacts are identified and discussed in detail. Applying such a model when engineering smart contracts will help software engineers and developers to better understand and streamline the engineering process of DLTs in general and blockchain in particular. Furthermore, this model serves as a generic framework which will support application development in all fields in which DLT can be applied.
... In practice, software systems evolve over time to remain satisfactory and respond to any changes in their environment [14] [25]. Changes are inevitable in any software system. ...
... There are several definitions of Software Evolution and Software Maintenance. Some authors refer to software evolution when new features or another aspect of the software is improved, and some authors relate to software maintenance mainly to the adaptations and fixes to keep the software running [14]. Since software maintenance objectives aim at reduced goals, maintenance processes are usually more straightforward and more predictable than the software evolution processes [25]. ...
... They must be continuously improved, adapted and fixed if they want to remain effective within a constantly evolving environment. Thus, the evolution of such systems is a complex phenomenon characterized by a multi-level, multi-loop and multi-agent feedback [14]. ...
Proprietary enterprise software is commonly embedded in multinational organizations and therefore has multiple sources of global or local demand. This type of software is subject to constant evolutions motivated by improvements in the features or by changes in the legal and economic context of its environment. Problems arising from the demand for requirements are associated with the suitability of a particular local requirement to its global context, for example: tax rules are characteristic of a specific country while a business rule can achieve every global structure. In addition, software customization can be implemented by the software producer, external partners, programmers allocated within the customer company, and so on. The coordination of this scenario is considered critical for the productive sector company that uses proprietary enterprise software. If the software does not evolve, the company processes can be temporarily compromised, and the software becomes obsolete. We report a case study of a large proprietary ERP system in a multinational company located in Brazil that is among the three largest exporters in its market segment. As a contribution, we present the current structure of the distributed evolution process of the software in question and how the stakeholder coordination of this scenario occurs.
... Software has the ability to enable or even advance changes in technology, economy, society, and humanity. To reflect these changes and endure relevancy to stakeholder, software is destined to evolve [1]. However, the increasing number of new maintenance and requirement requests often outgrows the ability of software languages. ...
The necessity of software evolution caused by novel requirements is often triggered alongside the advancement of underlying languages and tools. Although modern language workbenches decrease the opportunity cost of creating new language implementations, they do not offer automated and complete integration of existing languages. Moreover, they still require complex language engineering skills and extensive manual implementation effort to suit the expectations of domain experts, e.g., in terms of editor capabilities. In this work we present XMLIntellEdit—a framework for evolving domain-specific languages by automating the generation of modernized languages offering advanced editing capabilities, such as extended validation, content-assist, and quick fix solutions. Our approach builds on techniques from Model-Driven Engineering and Search-based Software Engineering research. Initial results indicate that XML Schema definitions containing restrictions can be applied for the automated generation of advanced editing facilities.
... Moreover, we can determinate what information systems can be considered as legacies from the functional or technological point of view [12]. Understanding by functional point of view the extent to which the functional requirements [13] of the business are fulfilled, while the technological point of view refers to the degree of obsolescence of the technology that was used to design and implement the information system [14] [15]. ...
Currently, there are information systems that were created decades ago but are still being used, today such technology is considered obsolete. In this context, new requirements, changes or improvements are more expensive because those systems are still playing a significant role in organizations and therefore need maintenance. This paper presents a basic process that enables us objectively identifying software assets in the organization, categorize different systems as legacy and finally prioritize modernization through four levels of action called: remove application, regular maintenance, conditional maintenance and modernization.
... Change is an essential element in software development, as software systems must respond to evolving requirements, platforms and other environmental pressures [1]. The software systems must thus reflect these changes to adequately fulfil their roles and remain relevant to stakeholders [2]. We have witnessed different industrial automation systems that have a lifetime of 10-30 years and are continuously changing. ...
The technique of virtualization and cloud computing to manage system functionality and resources regardless of their physical locations is changing the way businesses and users interact with IT resources. Although several commercially available virtualization solutions already exist in the market, both for server and embedded real-time based systems, the deployment of virtualization and cloud-based technologies into the industrial automation domain is new. In this paper, we will first present the emerging trends of industrial automation domain and identify the architectural sustainability challenges that follow. Based on these challenges, we will then analyze how virtualization technology can contribute to cope with them, as well as the additional opportunities that it brings to industrial automation domain. The contributions of this paper are (1) to communicate the main trends happening in industrial automation, (2) clarify the architecture sustainability challenges that the automation domain is facing, and (3) identify the potentials of further utilizing virtualization technology in the industry domain.
... More concisely, the ISO/IEC 9126 standard [1] states that maintainability is " the capability of the software product to be modified " 1 . Software maintenance is important because: (a) it consumes between 45% and 60% of the overall life cycle costs and, (b) the inability to change software quickly and reliably means that business opportunities may be lost [43]. However, practitioners still lack a body of practical evidence that soundly backs the maintainability advantages claimed by the MDE community [24, 45] . ...
Model-driven Engineering (MDE) approaches are often acknowledged to improve the maintainability of the resulting applications. However, there is a scarcity of empirical evidence that backs their claimed benefits and limitations with respect to code-centric approaches. The purpose of this paper is to compare the performance and satisfaction of junior software maintainers while executing maintainability tasks on Web applications with two different development approaches, one being OOH4RIA, a model-driven approach, and the other being a code-centric approach based on Visual Studio .NET and the Agile Unified Process. We have conducted a quasi-experiment with 27 graduated students from the University of Alicante. They were randomly divided into two groups, and each group was assigned to a different Web application on which they performed a set of maintainability tasks. The results show that maintaining Web applications with OOH4RIA clearly improves the performance of subjects. It also tips the satisfaction balance in favor of OOH4RIA, although not significantly. Model-driven development methods seem to improve both the developers’ objective performance and subjective opinions on ease of use of the method. This notwithstanding, further experimentation is needed to be able to generalize the results to different populations, methods, languages and tools, different domains and different application sizes.
Software evolution is the process of adapting, maintaining, and updating a software system. This process concentrates the most significant part of the software costs. Many works have studied software evolution and found relevant insights, such as Lehman's laws. However, there is a gap in how software systems evolve from an internal dimensions point of view. For instance, the literature has indicated how systems grow, for example, linearly, sub‐linearly, super‐linearly, or following the Pareto distribution. However, a well‐defined pattern of how this phenomenon occurs has not been established. This work aims to define a novel method to analyze and predict software evolution. We based our strategy on time series analysis, linear regression techniques, and trend tests. In this study, we applied the proposed model to investigate how the internal structure of object‐oriented software systems evolves in terms of four dimensions: coupling, inheritance hierarchy, cohesion, and class size. Applying the proposed method, we identify the functions that better explain how the analyzed dimensions evolve. Besides, we investigate how the relationship between dimension metrics behave over the systems' evolution and the set of classes existing in the systems that affect the evolution of these dimensions. We mined and analyzed data from 46 Java‐based open‐source projects. We used eight software metrics regarding the dimensions analyzed in this study. The main results of this study reveal ten software evolution properties, among them: coupling, cohesion, and inheritance evolve linearly; a relevant percentage of classes contributes to coupling and size evolution; a small percentage of classes contributes to cohesion evolution; there is no relation between the software internal dimensions' evolution. The results also indicate that our method can accurately predict how the software system will evolve in short‐term and long‐term predictions.
