物件導向軟體之架構(Object-Oriented Software Construction)探討

Aspect] is a simple and practical aspect-oriented extension to Java With just a few new constructs, AspectJ provides support for modular implementation of a range of crosscutting concerns. In AspectJ's dynamic join point model, join points are well-defined points in the execution of the program; pointcuts are collections of join points; advice are special method-like constructs that can be attached to pointcuts; and aspects are modular units of crosscutting implementation, comprising pointcuts, advice, and ordinary Java member declarations. AspectJ code is compiled into standard Java bytecode. Simple extensions to existing Java development environments make it possible to browse the crosscutting structure of aspects in the same kind of way as one browses the inheritance structure of classes. Several examples show that AspectJ is powerful, and that programs written using it are easy to understand.

An overview of AspectJ

Thank you for reading software product line engineering foundations principles and techniques. Maybe you have knowledge that, people have look numerous times for their favorite books like this software product line engineering foundations principles and techniques, but end up in malicious downloads. Rather than reading a good book with a cup of coffee in the afternoon, instead they are facing with some infectious bugs inside their desktop computer.

Software Product Line Engineering Foundations Principles And Techniques

Object-Oriented Software Metrics.

Code smells are symptoms of poor design and implementation choices that may hinder code comprehensibility and maintainability. Despite the effort devoted by the research community in studying code smells, the extent to which code smells in software systems affect software maintainability remains still unclear. In this paper we present a large scale empirical investigation on the diffuseness of code smells and their impact on code change- and fault-proneness. The study was conducted across a total of 395 releases of 30 open source projects and considering 17,350 manually validated instances of 13 different code smell kinds. The results show that smells characterized by long and/or complex code (e.g., Complex Class) are highly diffused, and that smelly classes have a higher change- and fault-proneness than smell-free classes.

/pdf/on-the-diffuseness-and-the-impact-on-maintainability-of-code-1qdl19a68u.pdf

On the diffuseness and the impact on maintainability of code smells: a large scale empirical investigation

Bad smells are symptoms that something may be wrong in the system design or code. There are many bad smells defined in the literature and detecting them is far from trivial. Therefore, several tools have been proposed to automate bad smell detection aiming to improve software maintainability. However, we lack a detailed study for summarizing and comparing the wide range of available tools. In this paper, we first present the findings of a systematic literature review of bad smell detection tools. As results of this review, we found 84 tools; 29 of them available online for download. Altogether, these tools aim to detect 61 bad smells by relying on at least six different detection techniques. They also target different programming languages, such as Java, C, C++, and C#. Following up the systematic review, we present a comparative study of four detection tools with respect to two bad smells: Large Class and Long Method. This study relies on two software systems and three metrics for comparison: agreement, recall, and precision. Our findings support that tools provide redundant detection results for the same bad smell. Based on quantitative and qualitative data, we also discuss relevant usability issues and propose guidelines for developers of detection tools.

A review-based comparative study of bad smell detection tools

A software product line (SPL) is a set of software systems that share a common and variable set of features. Software metrics provide basic means to quantify several modularity aspects of SPLs. However, the effectiveness of the SPL measurement process is directly dependent on the definition of reliable thresholds. If thresholds are not properly defined, it is difficult to actually know whether a given metric value indicates a potential problem in the feature implementation. There are several methods to derive thresholds for software metrics. However, there is little understanding about their appropriateness for the SPL context. This paper aims at comparing three methods to derive thresholds based on a benchmark of 33 SPLs. We assess to what extent these methods derive appropriate values for four metrics used in product-line engineering. These thresholds were used for guiding the identification of a typical anomaly found in features' implementation, named God Class. We also discuss the lessons learned on using such methods to derive thresholds for SPLs.

https://homepages.dcc.ufmg.br/~figueiredo/publications/splc15ready.pdf

Defining metric thresholds for software product lines: a comparative study

A software product line (SPL) is a set of software systems that share a common and variable set of components (features). Software metrics provide basic means to quantify several quality aspects of SPL components. However, the effectiveness of the SPL measurement process is directly dependent on the definition of reliable thresholds. If thresholds are not properly defined, it is difficult to actually know whether a given metric value indicates a potential problem in the component implementation. There are several methods to derive thresholds for software metrics. However, there is little understanding about their appropriateness for the context of SPLs. This paper aims to propose a method to derive thresholds in the SPL context. Our method is evaluated in terms of recall and precision using two code smells (God Class and Lazy Class) detection strategies. The evaluation of our method is performed based on a benchmark of 33 SPLs and the results were compared with a method (baseline) with the same purpose used in the context of SPLs (not proposed). The results show that our method has better recall when compared with baseline.

A Method to Derive Metric Thresholds for Software Product Lines

Software product line (SPL) is a set of software systems that share a common, managed set of features satisfying the specific needs of a particular market segment. Bad smells are symptoms that something may be wrong in system design. Bad smells in SPL are a relative new topic and need to be explored. This paper performed a Systematic Literature Review (SLR) to find and classify published work about bad smells in SPLs and their respective refactoring methods. Based on 18 relevant papers found in the SLR, we identified 70 bad smells and 95 refactoring methods related to them. The main contribution of this paper is a catalogue of bad smells and refactoring methods related to SPL.

Bad Smells in Software Product Lines: A Systematic Review

Software-intensive systems have been growing in both size and complexity. Consequently, developers need better support for measuring and controlling the software quality. In this context, software metrics aim at quantifying different software quality aspects. However, the effectiveness of measurement depends on the definition of reliable metric thresholds, i.e., numbers that characterize a metric value as critical given a quality aspect. In fact, without proper metric thresholds, it might be difficult for developers to indicate problematic software components for correction, for instance. Based on a literature review, we have found several existing methods for deriving metric thresholds and observed their evolution. Such evolution motivated us to propose a new method that incorporates the best of the existing methods. In this paper, we propose a novel benchmark-based method for deriving metric thresholds. We assess our method, called Vale’s method, using a set of metric thresholds derived with the support of our method, aimed at composing detection strategies for two well-known code smells, namely god class and lazy class. For this purpose, we analyze three benchmarks composed of multiple software product lines. In addition, we demonstrate our method in practice by applying it to a benchmark composed of 103 Java open-source software systems. In the evaluation, we compare Vale’s method to two state-of-the-practice threshold derivation methods selected as a baseline, which are Lanza’s method and Alves’ method. Our results suggest that the proposed method provides more realistic and reliable thresholds, with better recall and precision in the code smell detection, when compared to both baseline methods.

Gustavo Vale

Papers

A review-based comparative study of bad smell detection tools

Defining metric thresholds for software product lines: a comparative study

A Method to Derive Metric Thresholds for Software Product Lines

Bad Smells in Software Product Lines: A Systematic Review

On the proposal and evaluation of a benchmark-based threshold derivation method