7 research outputs found
Language Interaction and Quality Issues: An Exploratory Study
Most software systems are complex and often composed of a large number of artifacts. To realize each different artifacts specific techniques are used resorting on different abstractions, languages and tools. Successful composition of different elements requires coherence among them. Unfortunately constraints between artifacts written in different languages are usually not formally expressed neither checked by supporting tools; as consequence they can be a source of problems. In this paper we explore the role of the relations between artifacts written in different languages by means of a case study on the Hadoop open source project. We present the problem introducing the related terminology, we quantify the phenomenon and investigate the relation with defect pronenes
EMPIRICAL ASSESSMENT OF THE IMPACT OF USING AUTOMATIC STATIC ANALYSIS ON CODE QUALITY
Automatic static analysis (ASA) tools analyze the source or compiled code looking for violations of recommended programming practices (called issues) that might cause faults or might degrade some dimensions of software quality. Antonio Vetro' has focused his PhD in studying how applying ASA impacts software quality, taking as reference point the different quality dimensions specified by the standard ISO/IEC 25010. The epistemological approach he used is that one of empirical software engineering. During his three years PhD, he's been conducting experiments and case studies on three main areas: Functionality/Reliability, Performance and Maintainability. He empirically proved that specific ASA issues had impact on these quality characteristics in the contexts under study: thus, removing them from the code resulted in a quality improvement. Vetro' has also investigated and proposed new research directions for this field: using ASA to improve software energy efficiency and to detect the problems deriving from the interaction of multiple languages. The contribution is enriched with the final recommendation of a generalized process for researchers and practitioners with a twofold goal: improve software quality through ASA and create a body of knowledge on the impact of using ASA on specific software quality dimensions, based on empirical evidence. This thesis represents a first step towards this goa
Towards Better Static Analysis Security Testing Methodologies
Software vulnerabilities have been a significant attack surface used in cyberattacks, which
have been escalating recently. Software vulnerabilities have caused substantial damage,
and thus there are many techniques to guard against them. Nevertheless, detecting and
eliminating software vulnerabilities from the source code is the best and most effective solution
in terms of protection and cost. Static Analysis Security Testing (SAST) tools spot
vulnerabilities and help programmers to remove the vulnerabilities. The fundamental problem
is that modern software continues to evolve and shift, making detecting vulnerabilities
more difficult. Hence, this thesis takes a step toward highlighting the features required to
be present in the SAST tools to address software vulnerabilities in modern software. The
thesis’s end goal is to introduce SAST methods and tools to detect the dominant type of
software vulnerabilities in modern software. The investigation first focuses on state-of-theart
SAST tools when working with large-scale modern software. The research examines
how different state-of-the-art SAST tools react to different types of warnings over time,
and measures SAST tools precision of different types of warnings. The study presumption
is that the SAST tools’ precision can be obtained from studying real-world projects’ history
and SAST tools that generated warnings over time. The empirical analysis in this
study then takes a further step to look at the problem from a different angle, starting at
the real-world vulnerabilities detected by individuals and published in well-known vulnerabilities
databases. Android application vulnerabilities are used as an example of modern
software vulnerabilities. This study aims to measure the recall of SAST tools when they
work with modern software vulnerabilities and understand how software vulnerabilities
manifest in the real world. We find that buffer errors that belong to the input validation
and representation class of vulnerability dominate modern software. Also, we find that
studied state-of-the-art SAST tools failed to identify real-world vulnerabilities. To address
the issue of detecting vulnerabilities in modern software, we introduce two methodologies.
The first methodology is a coarse-grain method that targets helping taint static analysis
methods to tackle two aspects of the complexity of modern software. One aspect is that
one vulnerability can be scattered across different languages in a single application making
the analysis harder to achieve. The second aspect is that the number of sources and
sinks is high and increasing over time, which can be hard for taint analysis to cover such
a high number of sources and sinks. We implement the proposed methodology in a tool
called Source Sink (SoS) that filters out the source and sink pairs that do not have feasible
paths. Then, another fine-grain methodology focuses on discovering buffer errors that
occur in modern software. The method performs taint analysis to examine the reachability
between sources and sinks and looks for "validators" that validates the untrusted input.
We implemented methodology in a tool called Buffer Error Finder (BEFinder)
Generic Quality-Aware Refactoring and Co-Refactoring in Heterogeneous Model Environments
Software has been subject to change, at all times, in order to make parts of it, for instance, more reusable, better to understand by humans, or to increase efficiency under a certain point of view. Restructurings of existing software can be complex. To prevent developers from doing this manually, they got tools at hand being able to apply such restructurings automatically. These automatic changes of existing software to improve quality while preserving its behaviour is called refactoring. Refactoring is well investigated for programming languages and mature tools exist for executing refactorings in integrated development environments (IDEs).
In recent years, the development paradigm of Model-Driven Software Development (MDSD) became more and more popular and we experience a shift in the sense that development artefacts are considered as models which conform metamodels. This can be understood as abstraction, which resulted in the trend that a plethora of new so-called model-based Domain-Specific Languages (DSLs) arose. DSLs have become an integral part in the MDSD and it is obvious that models are subject to change, as well. Thus, refactoring support is required for DSLs in order to prevent users from doing it manually.
The problem is that the amount of DSLs is huge and refactorings should not be implemented for new for each of them, since they are quite similar from an abstract viewing. Existing approaches abstract from the target language, which is not flexible enough because some assumptions about the languages have to be made and arbitrary DSLs are not supported. Furthermore, the relation between a strategy which finds model deficiencies that should be improved, a resolving refactoring, and the improved quality is only implicit. Focussing on a particular quality and only detecting those deficiencies deteriorating this quality is difficult, and elements of detected deficient structures cannot be referred to in the resolving refactoring.
In addition, heterogeneous models in an IDE might be connected physically or logically, thus, they are dependent. Finding such connections is difficult and can hardly be achieved manually. Applying a restructuring in a model implied by a refactoring in a dependent model must also be a refactoring, in order to preserve the meaning. Thus, this kind of dependent refactorings require an appropriate abstraction mechanism, since they must be specified for dependent models of different DSLs.
The first contribution, Role-Based Generic Model Refactoring, uses role models to abstract from refactorings instead of the target languages. Thus, participating structures in a refactoring can be specified generically by means of role models. As a consequence, arbitrary model-based DSLs are supported, since this approach does not make any assumptions regarding the target languages.
Our second contribution, Role-Based Quality Smells, is a conceptual framework and correlates deficiencies, their deteriorated qualities, and resolving refactorings. Roles are used to abstract from the causing structures of a deficiency, which then are subject to resolving refactorings.
The third contribution, Role-Based Co-Refactoring, employs the graph-logic isomorphism to detect dependencies between models. Dependent refactorings, which we call co-refactorings, are specified on the basis of roles for being independent from particular target DSLs.
All introduced concepts are implemented in our tool Refactory. An evaluation in different scenarios complements the thesis. It shows that role models emerged as very powerful regarding the reuse of generic refactorings in arbitrary languages. Role models are suited as an interface for certain structures which are to be refactored, scanned for deficiencies, or co-refactored. All of the presented approaches benefit from it.:List of Figures xv
List of Tables xvii
List of Listings xix
1. Introduction 1
1.1. Language-Tool Generation Without Consideration Of Time And Space . . . . . 4
1.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3. Generic Quality-Aware Refactoring and Co-Refactoring in Heterogeneous Model
Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Foundations 15
2.1. Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2. Model-Driven Software Development . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1. Levels of Abstraction and Metamodelling . . . . . . . . . . . . . . . . . 17
2.2.2. Model Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3. Role-Based Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3. Related Work 23
3.1. Model Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.2. Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.3. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2. Determination of Quality-Related De ciencies . . . . . . . . . . . . . . . . . . . 32
3.2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.2. Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.3. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3. Co-Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.2. Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.3. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4. Role-Based Generic Model Refactoring 51
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2. Specifying Generic Refactorings with Role Models . . . . . . . . . . . . . . . . . 53
4.2.1. Specifying Structural Constraints using Role Models . . . . . . . . . . . 55
4.2.2. Mapping Roles to Language Concepts Using Role Mappings . . . . . . . 57
4.2.3. Specifying Language-Independent Transformations using Refactoring
Speci cations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.4. Composition of Refactorings . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3. Preserving Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5. Suggesting Role Mappings as Concrete Refactorings 73
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2. Automatic Derivation of Suggestions for Role Mappings with Graph Querying . 74
5.3. Reduction of the Number of Valid Matches . . . . . . . . . . . . . . . . . . . . . 76
5.4. Comparison to Model Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6. Role-Based Quality Smells as Refactoring Indicator 79
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.2. Correlating Model De ciencies, Qualities and Refactorings . . . . . . . . . . . . 80
6.2.1. Quality Smell Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.2.2. Quality Smell Calculation Repository . . . . . . . . . . . . . . . . . . . . 85
6.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7. A Quality Smell Catalogue for Android Applications 89
7.1. Quality Smell Catalogue Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.2. Acquiring Quality Smells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.3. Structure-Based Quality Smells—A Detailed Example . . . . . . . . . . . . . . . 92
7.3.1. The Pattern Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.3.2. Quality Smell: Interruption from Background . . . . . . . . . . . . . . . 93
7.4. Quality Smells for Android Applications . . . . . . . . . . . . . . . . . . . . . . 96
7.4.1. Quality Smell: Data Transmission Without Compression . . . . . . . . . 96
7.4.2. Quality Smell: Dropped Data . . . . . . . . . . . . . . . . . . . . . . . . 98
7.4.3. Quality Smell: Durable WakeLock . . . . . . . . . . . . . . . . . . . . . 98
7.4.4. Quality Smell: Internal Use of Getters/Setters . . . . . . . . . . . . . . . 99
7.4.5. Quality Smell: No Low Memory Resolver . . . . . . . . . . . . . . . . . 101
7.4.6. Quality Smell: Rigid AlarmManager . . . . . . . . . . . . . . . . . . . . 101
7.4.7. Quality Smell: Unclosed Closeable . . . . . . . . . . . . . . . . . . . . . 102
7.4.8. Quality Smell: Untouchable . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
8. Role-Based Co-Refactoring in Multi-Language Development Environments 105
8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.3. Dependency Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
8.3.1. Categories of Model Dependencies . . . . . . . . . . . . . . . . . . . . . 108
8.3.2. When to Determine Model Dependencies . . . . . . . . . . . . . . . . . 110
8.3.3. How to Determine Model Dependencies . . . . . . . . . . . . . . . . . . 111
8.4. Co-Refactoring Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.4.1. Specifying Coupled Refactorings with Co-Refactoring Speci cations . . 114
8.4.2. Specifying Bindings for Co-Refactorings . . . . . . . . . . . . . . . . . . 116
8.4.3. Determination of Co-Refactoring Speci cations . . . . . . . . . . . . . . 118
8.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
9. Refactory: An Eclipse Tool For Quality-Aware Refactoring and Co-Refactoring 121
9.1. Refactoring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
9.1.1. Role Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
9.1.2. Refactoring Speci cation . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
9.1.3. Role Model Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.1.4. Refactoring Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
9.1.5. Custom Refactoring Extensions . . . . . . . . . . . . . . . . . . . . . . . 129
9.1.6. Pre- and Post-conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
9.1.7. Integration Into the Eclipse Refactoring Framework . . . . . . . . . . . . 130
9.2. Quality Smell Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
9.3. Co-Refactoring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
9.3.1. Concrete Syntax of a CoRefSpec . . . . . . . . . . . . . . . . . . . . . . . 138
9.3.2. Expression Evaluation by Using an Expression Language . . . . . . . . . 138
9.3.3. UI and Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
9.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
10. Evaluation 143
10.1. Case Study: Reuse of Generic Refactorings in many DSLs . . . . . . . . . . . . . 143
10.1.1. Threats to validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
10.1.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
10.1.3. Experience Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
10.2. Case Study: Suggestion of Valid Role Mappings . . . . . . . . . . . . . . . . . . 147
10.2.1. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
10.2.2. Evaluation and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 151
10.3. Proof of Concept: Co-Refactoring OWL and Ecore Models . . . . . . . . . . . . 155
10.3.1. Coupled OWL-Ecore Refactorings . . . . . . . . . . . . . . . . . . . . . 156
10.3.2. Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
11. Summary, Conclusion and Outlook 161
11.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
11.2. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
11.3. Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Appendix 169
A. List of Role Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
B. Comparison to Role Feature Model . . . . . . . . . . . . . . . . . . . . . . . . . 171
C. Complete List of Role Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
D. List of all IncPL Patterns for Detecting Quality Smells . . . . . . . . . . . . . . . 176
E. Post-Processor of the Extract CompositeState refactoring for UML State Machines 183
F. Speci cation of the Conference Language . . . . . . . . . . . . . . . . . . . . . . 185
List of Abbreviations 187
Bibliography 19
Agnostic content ontology design patterns for a multi-domain ontology
This research project aims to solve the semantic heterogeneity problem. Semantic heterogeneity mimics cancer in that semantic heterogeneity unnecessarily consumes resources from its host, the enterprise, and may even affect lives. A number of authors report that semantic heterogeneity may cost a significant portion of an enterprise’s IT budget. Also, semantic heterogeneity hinders pharmaceutical and medical research by consuming valuable research funds.
The RA-EKI architecture model comprises a multi-domain ontology, a cross-industry agnostic construct composed of rich axioms notably for data integration. A multi-domain ontology composed of axiomatized agnostic data model patterns would drive a cognitive data integration application system usable in any industry sector. This project’s objective is to elicit agnostic data model patterns here considered as content ontology design patterns. The first research question of this project pertains to the existence of agnostic patterns and their capacity to solve the semantic heterogeneity problem. Due to the theory-building role of this project, a qualitative research approach constitutes the appropriate manner to conduct its research. Contrary to theory testing quantitative methods that rely on well-established validation techniques to determine the reliability of the outcome of a given study, theorybuilding qualitative methods do not possess standardized techniques to ascertain the reliability of a study. The second research question inquires on a dual method theory-building approach that may demonstrate trustworthiness. The first method, a qualitative Systematic Literature Review (SLR) approach induces the sought knowledge from 69 retained publications using a practical screen. The second method, a phenomenological research protocol elicits the agnostic concepts from semi-structured interviews involving 22 senior practitioners with 21 years in average of experience in conceptualization.
The SLR retains a set of 89 agnostic concepts from 2009 through 2017. The phenomenological study in turn retains 83 agnostic concepts. During the synthesis stage for both studies, data saturation was calculated for each of the retained concepts at the point where the concepts have been selected for a second time. The quantification of data saturation constitutes an element of the trustworthiness’s transferability criterion. It can be argued that this effort of establishing the trustworthiness, i.e. credibility, dependability, confirmability and transferability can be construed as extensive and this research track as promising. Data saturation for both studies has still not been reached. The assessment performed in the course of the establishment of trustworthiness of this project’s dual method qualitative research approach yields very interesting findings. Such findings include two sets of agnostic data model patterns obtained from research protocols using radically different data sources i.e. publications vs. experienced practitioners but with striking similarities. Further work is required using exactly the same protocols for each of the methods, expand the year range for the SLR and to recruit new co-researchers for the phenomenological protocol. This work will continue until these protocols do not elicit new theory material. At this point, new protocols for both methods will be designed and executed with the intent to measure theoretical saturation. For both methods, this entails in formulating new research questions that may, for example, focus on agnostic themes such as finance, infrastructure, relationships, classifications, etc. For this exploration project, the road ahead involves the design of new questionnaires for semi-structured interviews. This project will need to engage in new knowledge elicitation techniques such as focus groups. The project will definitely conduct other qualitative research methods such as research action for eliciting new knowledge and know-how from actual development and operation of an ontology-based cognitive application. Finally, a mixed methods qualitative-quantitative approach would prepare the transition toward theory testing method using hypothetico-deductive techniques