An automated approach for noise identification to assist software architecture recovery techniques

Constantinou, Eleni; Kakarontzas, George; Stamelos, Ioannis

doi:10.1016/j.jss.2015.05.065

Cited by 7 publications

(10 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The IC1, IC2, EC4, EC5, and EC6 criteria were applied. Finally, after applying the three rounds and the IC and EC, 36 primary studies were obtained (see Table 3 ). The data extraction and synthesis processes for the 36 primary studies were conducted by using a form in which each study was identified with ID [13–15, 18, 22–53 ] and classified according to its context, validation, terminology, and usefulness in answering each research question.…”

Section: Methodsmentioning

confidence: 99%

“…The works [22, 28, 36, 39, 43, 49 ] define processes for architectural reconstruction. These processes combine techniques such as dynamic, static, and clustering analysis as well as bottom‐up and top‐down strategies to obtain architectural views as output (code, structural, and process views).…”

Section: Reconstruction and Reverse Engineering Of Software Architementioning

confidence: 99%

See 1 more Smart Citation

Towards a reference process for software architecture reconstruction

et al. 2020

View full text Add to dashboard Cite

Nowadays, software systems remain useful and competitive; entail the inevitable need to change over time and to be adapted to new technologies, platforms, and architectures. These quick changes imply following systematic, automated, or standardised processes that provide recommendations and guidelines to architects during software architecture reconstruction. Considerable research work on architecture reconstruction has been conducted. However, it needs to be studied thoroughly to determine what are the common activities and elements to reconstruct software architectures, and to define a reference process for systematically guiding the evolution of software architectures. This work addresses the need for defining a process for software architecture reconstruction called software improvement in the reconstruction of architectures (SIRA). This process has been rigorously designed from the results of a systematic literature review and a small survey of related work. As a result, SIRA integrates and extends previous research and can be conceived as a reference process to reconstruct software architectures in a semi‐automated way. In addition, this work also determines the common elements of the architecture reconstruction process: (i) techniques and activities; (ii) architectural elements, patterns, and attributes; (iii) mechanisms and strategies; and (iv) the automation and recommendation tasks of the process.

show abstract

Section: Methodsmentioning

confidence: 99%

Section: Reconstruction and Reverse Engineering Of Software Architementioning

confidence: 99%

Towards a reference process for software architecture reconstruction

et al. 2020

View full text Add to dashboard Cite

show abstract

“…They experimentally demonstrated that using an accurate dependency could improve the quality of existing architecture recovery techniques. Furthermore, Constantinou et al [12] emphasized that structurally-noisy classes must be identified in a preparatory procedure for architecture recovery. They computed a class's significance value using graph theory techniques and classified omnipresent classes as noises according to their significance values.…”

Section: A Software Architecture Recoverymentioning

confidence: 99%

“…Several studies have considered the quality of software entities and their relationships for architecture recovery [12], [13]. The common argument is that low-quality software dependency information and structural noise harm architecture recovery.…”

Section: Introductionmentioning

confidence: 99%

Identifying Semantic Outliers of Source Code Artifacts and Their Application to Software Architecture Recovery

Lee

2020

IEEE Access

View full text Add to dashboard Cite

Understanding software architecture is essential to software maintenance. There has been much effort to derive software architecture views from source code artifacts. Typically, along with structural information, the semantic information derived from an identifier name and comments are helpful. However, because code vocabulary choice depends on a developer's subjective decision, some source code may have semantically low text quality, leading to an inaccurate architecture recovery. This paper aims to improve the architecture recovery of a software system by identifying and removing the semantic outliers of source code artifacts. Accordingly, we propose a novel measure Conceptual Conformity (CC), which computes the similarity between two latent topic distributions obtained from both the source code and its package. We use CC to identify source code that is not relevant to the package's semantic context and define it as a semantic outlier. Because the semantic outliers may cause inaccurate architecture recovery, we remove them during the recovery process. We apply our approach to three opensource projects. The results demonstrate that, for projects with low recovery performance, removing outliers leads to higher recovery accuracy.

show abstract

“…Many approaches address the architecture-implementation mapping issue by ignoring the prescriptive architecture and simply trying to obtain the most accurate descriptive architectures possible [25,35,42,34,29,28,50,58,21,53]. A large number of these approaches rely on software clustering to determine components from implementations [62,47,25,35,14].…”

Section: Related Workmentioning

confidence: 99%

Detection and Repair of Architectural Inconsistencies in Java

Ghorbani

Garcia

Malek

2019

2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)

View full text Add to dashboard Cite

Java is one of the most widely used programming languages. However, the absence of explicit support for architectural constructs, such as software components, in the programming language itself has prevented software developers from achieving the many benefits that come with architecture-based development. To address this issue, Java 9 has introduced the Java Platform Module System (JPMS), resulting in the first instance of encapsulation of modules with rich software architectural interfaces added to a mainstream programming language. The primary goal of JPMS is to construct and maintain large applications efficiently-as well as improve the encapsulation, security, and maintainability of Java applications in general and the JDK itself. A challenge, however, is that module declarations do not necessarily reflect actual usage of modules in an application, allowing developers to mistakenly specify inconsistent dependencies among the modules. In this thesis, we formally define 8 inconsistent modular dependencies that may arise in Java-9 applications. We also present Darcy, an approach that leverages these definitions and static program analyses to automatically (1) detect the specified inconsistent dependencies within Java applications and (2) repair those identified inconsistencies. The results of our experiments, conducted over 38 open-source Java-9 applications, indicate that architectural inconsistencies are widespread and demonstrate the benefits of Darcy in automated detection and repair of these inconsistencies. vii

show abstract

An automated approach for noise identification to assist software architecture recovery techniques

Cited by 7 publications

References 23 publications

Towards a reference process for software architecture reconstruction

Towards a reference process for software architecture reconstruction

Identifying Semantic Outliers of Source Code Artifacts and Their Application to Software Architecture Recovery

Detection and Repair of Architectural Inconsistencies in Java

Contact Info

Product

Resources

About