Spelling suggestions: "subject:"heterogeneous model"" "subject:"eterogeneous model""
1 |
The Influence of Geometry on the Performance of Catalytic ConverterNajafi Marghmaleki, Amirhassan 11 1900 (has links)
In this thesis, the development and use of a transient heterogeneous 2D model for monolithic catalytic converter is presented. Study on the cold flow hydrodynamics, temperature effect and CO conversion and light off behaviour of different models is developed. Different models are studied based on different parameters such as monolith brick CPSI configuration, size of the converter, inlet cone sizing and inlet velocity of the converter. The results for both steady state and transient modes are presented in detail.
It is shown that monolith brick CPSI has a significant effect on pressure drop and light-off behaviour of the converter. Also, converter size has a major effect on the performance of a converter. Inlet cone sizing showed to have a significant effect on the hydrodynamics of the converter but it did not have a major effect on light-off behaviour of the converter. / Chemical Engineering
|
2 |
The Influence of Geometry on the Performance of Catalytic ConverterNajafi Marghmaleki, Amirhassan Unknown Date
No description available.
|
3 |
Mathematical Modeling of Epidemics: Parametric Heterogeneity and Pathogen CoexistenceSarfo Amponsah, Eric January 2020 (has links)
No two species can indefinitely occupy the same ecological niche according to the competitive exclusion principle. When competing strains of the same pathogen invade a homogeneous population, the strain with the largest basic reproductive ratio R0 will force the other strains to extinction. However, over 51 pathogens are documented to have multiple strains [3] coexisting, contrary to the results from homogeneous models. In reality, the world is heterogeneous with the population varying in susceptibility. As such, the study of epidemiology, and hence the problem of pathogen coexistence should entail heterogeneity. Heterogeneous models tend to capture dynamics such as resistance to infection, giving more accurate results of the epidemics. This study will focus on the behavior of multi-pathogen heterogeneous models and will try to answer the question: what are the conditions on the model parameters that lead to pathogen coexistence? The goal is to understand the mechanisms in heterogeneous populations that mediate pathogen coexistence. Using the moment closure method, Fleming et. al. [22] used a two pathogen heterogeneous model (1.9) to show that pathogen coexistence was possible between strains of the baculovirus under certain conditions. In the first part of our study, we consider the same model using the hidden keystone variable (HKV) method. We show that under some conditions, the moment closure method and the HKV method give the same results. We also show that pathogen coexistence is possible for a much wider range of parameters, and give a complete analysis of the model (1.9), and give an explanation for the observed coexistence.
The host population (gypsy moth) considered in the model (1.9) has a year life span, and hence, demography was introduced to the model using a discrete time model (1.12). In the second part of our study, we will consider a multi-pathogen compartmental heterogeneous model (3.1) with continuous time demography. We show using a Lyapunov function that pathogen coexistence is possible between multiple strains of the same pathogen. We provide analytical and numerical evidence that multiple strains of the same pathogen can coexist in a heterogeneous population.
|
4 |
Kinetic parameter estimation and simulation of trickle-bed reactor for hydrodesulfurization of crude oilJarullah, Aysar Talib, Mujtaba, Iqbal M., Wood, Alastair S. January 2011 (has links)
No
|
5 |
Improving fuel quality by whole crude oil hydrotreating: A kinetic model for hydrodeasphaltenization in a trickle bed reactorJarullah, Aysar Talib, Mujtaba, Iqbal M., Wood, Alastair S. January 2012 (has links)
No / Fossil fuel is still a predominant source of the global energy requirement. Hydrotreating of whole crude oil has the ability to increase the productivity of middle distillate fractions and improve the fuel quality by simultaneously reducing contaminants such as sulfur, nitrogen, vanadium, nickel and asphaltene to the levels required by the regulatory bodies. Hydrotreating is usually carried out in a trickle bed reactor (TBR) where hydrodesulfurization (HDS), hydrodenitrogenation (HDN), hydrodemetallization (HDM) and hydrodeasphaltenization (HDAs) reactions take place simultaneously. To develop a detailed and a validated TBR process model which can be used for design and optimization of the hydrotreating process, it is essential to develop kinetic models for each of these reactions. Most recently, the authors have developed kinetic models for all of these chemical reactions except that of HDAs. In this work, a kinetic model (in terms of kinetic parameters) for the HDAs reaction in the TBR is developed.
A three phase TBR process model incorporating the HDAs reactions with unknown kinetic parameters is developed. Also, a series of experiments has been conducted in an isothermal TBR under different operating conditions affecting the removal of asphaltene. The unknown kinetic parameters are then obtained by applying a parameter estimation technique based on minimization of the sum of square errors (SSEs) between the experimental and predicted concentrations of asphaltene compound in the crude oil.
The full model with the estimated kinetic parameters is then applied to evaluate the removal of asphaltene (thus affecting fuel quality) under different operating conditions (than those used in experiments).
|
6 |
Generic Quality-Aware Refactoring and Co-Refactoring in Heterogeneous Model EnvironmentsReimann, Jan 27 August 2015 (has links) (PDF)
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.
|
7 |
Generic Quality-Aware Refactoring and Co-Refactoring in Heterogeneous Model EnvironmentsReimann, Jan 09 July 2015 (has links)
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 191
|
Page generated in 0.0639 seconds