Memon Advances in Computers

1. Auflage 2015
ISBN: 978-0-12-802341-9
Verlag: Elsevier Science & Techn.
Format: EPUB
Kopierschutz: Adobe DRM (»Systemvoraussetzungen)

E-Book, Englisch, Band Volume 97, 276 Seiten

Reihe: Advances in Computers

Since its first volume in 1960, Advances in Computers has presented detailed coverage of innovations in computer hardware, software, theory, design, and applications. It has also provided contributors with a medium in which they can explore their subjects in greater depth and breadth than journal articles usually allow. As a result, many articles have become standard references that continue to be of significant, lasting value in this rapidly expanding field. - In-depth surveys and tutorials on new computer technology - Well-known authors and researchers in the field - Extensive bibliographies with most chapters - Many of the volumes are devoted to single themes or subfields of computer science

Autoren/Hrsg.

Memon, Atif

Inhaltsverzeichnis

1;Front Cover;1
2;Advances in Computers;4
3;Copyright;5
4;Contents;6
5;Preface;10
6;Chapter 1: Comparing Reuse Strategies in Different Development Environments;12
6.1;1. Introduction;13
6.2;2. Development Approaches for Embedded and Nonembedded Systems with Reuse;15
6.2.1;2.1. Development Approaches;15
6.2.2;2.2. Embedded versus Nonembedded Systems;18
6.2.3;2.3. Types of Empirical Studies;19
6.3;3. Review Process and Inclusion Criteria;20
6.4;4. Reuse and Development Approaches for Embedded versus Nonembedded Systems;22
6.4.1;4.1. Software Reuse in Embedded Systems;23
6.4.2;4.2. Software Reuse in Nonembedded Systems;25
6.4.3;4.3. Software Reuse in Embedded and Nonembedded Systems;27
6.4.4;4.4. Comparing Study Types;30
6.5;5. Metrics Reported;30
6.6;6. Analysis of Outcomes;33
6.7;7. Threats to Validity;46
6.8;8. Conclusion and Future Work;49
6.9;Acknowledgments;51
6.10;Appendix A: Years of Publication;51
6.11;References;52
7;Chapter 2: Advances in Behavior Modeling;60
7.1;1. Introduction;61
7.2;2. Properties of the Modeling Semantics Needed for System Life Cycle Support;62
7.3;3. Events, States, Transitions, and Communication-Composition;64
7.3.1;3.1. Events;65
7.3.1.1;3.1.1. Abstract Events Versus Structured Messages;65
7.3.1.2;3.1.2. Events as Inputs Versus Inputs and Outputs;66
7.3.2;3.2. States;66
7.3.2.1;3.2.1. Abstract States Versus States with Variables;66
7.3.2.2;3.2.2. State Localized Versus Distributed;66
7.3.3;3.3. Transitions;66
7.3.3.1;3.3.1. Transitions with Can, Must, Motivate Semantics;67
7.3.3.2;3.3.2. Transitions That Update States Versus Transition That Update States and Variables;67
7.3.4;3.4. Communication of LTSs and Composition;67
7.3.4.1;3.4.1. CCS Composition;69
7.3.4.2;3.4.2. CSP Composition;70
7.3.4.3;3.4.3. Combined Composition Semantics;70
7.3.5;3.5. Choice of a Behavior Modeling Semantics;71
7.4;4. Behavior Semantics in UML;71
7.4.1;4.1. Use Cases;72
7.4.2;4.2. Sequence Diagrams;74
7.4.3;4.3. Activity Diagrams;75
7.4.4;4.4. State Machines (UML);78
7.4.4.1;4.4.1. UML Behavior State Machines;78
7.4.4.2;4.4.2. UML Protocol State Machines;82
7.5;5. Outside UML;83
7.5.1;5.1. Classical Petri Nets;83
7.5.1.1;5.1.1. Classical Petri Nets Semantics;83
7.5.1.2;5.1.2. A Petri Net of a Web Service;84
7.5.1.3;5.1.3. Model Changes;85
7.5.2;5.2. Colored Petri Nets;87
7.5.2.1;5.2.1. Colored Petri Nets Semantics;88
7.5.2.2;5.2.2. Colored Petri Net of a Mobile Phone with Phone Book;89
7.5.2.3;5.2.3. Model Changes;90
7.5.3;5.3. Protocol Modeling;92
7.5.3.1;5.3.1. Protocol Modeling Semantics;94
7.5.3.2;5.3.2. Protocol Model of a Mobile Phone with Phone Book;96
7.5.3.3;5.3.3. Model Changes;101
7.5.3.4;5.3.4. Can and Must Semantics;103
7.5.3.5;5.3.5. Motivation Semantics;106
7.5.3.6;5.3.6. Combining the CCS and CSP Parallel Composition in Protocol Models;109
7.6;6. Summary of Semantic Elements of Behavior Modeling Approaches and Their Properties;111
7.7;Acknowledgments;117
7.8;References;117
8;Chapter 3: Overview of Computational Approaches for Inference of MicroRNA-Mediated and Gene Regulatory Networks;122
8.1;1. Introduction;123
8.2;2. Biological Backgrounds of Cell Regulatory Mechanisms and Experimental Technologies;125
8.3;3. Computational Backgrounds of the Inference of MiRNA-Mediated and GRNs;127
8.4;4. Models for GRNs Inference;129
8.4.1;4.1. Boolean Networks;129
8.4.2;4.2. Bayesian Networks;131
8.4.3;4.3. Dynamic Bayesian Networks;132
8.4.4;4.4. Association Networks;135
8.4.5;4.5. Differential and Difference Equations Models;137
8.4.6;4.6. Other Models for Inference of GRNs;139
8.4.7;4.7. Recent Models for Inference of GRNs by Integration of A Priori Knowledge;140
8.5;5. Computational Approaches for Inference of MicroRNA-Mediated Regulatory Networks;142
8.5.1;5.1. MicroRNA-Mediated Regulatory Networks;142
8.5.2;5.2. Types of Regulatory Relationships;142
8.5.3;5.3. Robustness of miRNA-Mediated Regulatory Networks;147
8.6;6. Model Validation;148
8.7;7. Conclusion and Further Works;150
8.8;References;151
9;Chapter 4: Proving Programs Terminate Using Well-Founded Orderings, Ramsey´s Theorem, and Matrices;158
9.1;1. Introduction;159
9.2;2. Notation and Definitions;160
9.3;3. A Proof Using the Order (N, );163
9.4;4. A Proof Using the Ordering (N x N x N x N, lex);164
9.5;5. A General Theorem About Proving Programs Terminate Using Well-Founded Orderings;166
9.6;6. A Proof Using Ramsey´s Theorem;167
9.7;7. A General Theorem About Proving Programs Terminate Using Ramsey Theorem;168
9.8;8. A Proof Using Matrices and Ramsey´s Theorem;171
9.9;9. Another Proof Using Matrices and Ramsey´s Theorem;176
9.10;10. A Proof Using Transition Invariants and Ramsey´s Theorem;179
9.11;11. Another Proof Using Transition Invariants and Ramsey´s Theorem;183
9.12;12. Solving Subcases of the Termination Problem;184
9.13;13. How Much Ramsey Theory Do We Need?;187
9.13.1;13.1. Reverse Mathematics;187
9.13.2;13.2. Computable Mathematics;188
9.13.3;13.3. Finitary Version;189
9.14;14. Open Problems;190
9.15;15. Summary;190
9.16;Acknowledgments;191
9.17;A. Using Just C1 and C2 to Prove Termination;191
9.18;B. A Verification That Needs the Full Ramsey Theory;192
9.19;C. Ramsey´s Theorem;193
9.19.1;C.1.. If There Are Six People at a Party;193
9.19.2;C.2.. Notation;195
9.19.3;C.3.. Proof of the Infinite Ramsey Theorem;196
9.19.4;C.4.. Proof of the Finite Ramsey Theorem from the Infinite Ramsey Theorem;198
9.19.5;C.5.. A Direct Proof of the Finite Ramsey´s Theorem;199
9.19.6;C.6.. Another Direct Proof of the Finite Ramsey´s Theorem;201
9.19.7;C.7.. Our Last Word on Ramsey Numbers;204
9.20;D. The Transitive Ramsey Theorem;205
9.20.1;D.1.. A Common Math Competition Problem;205
9.20.2;D.2.. View in Terms of Colorings;207
9.20.3;D.3.. The Transitive Ramsey Theorem;207
9.21;References;208
10;Chapter 5: Advances in Testing JavaScript-Based Web Applications;212
10.1;1. Introduction;213
10.2;2. Empirical Studies;215
10.2.1;2.1. Insecure JavaScript Inclusions;215
10.2.2;2.2. Dynamic JavaScript Features;215
10.2.3;2.3. Dynamic DOM Induced by JavaScript;216
10.2.4;2.4. JavaScript Bugs;218
10.3;3. Testing Techniques;219
10.3.1;3.1. Industrial Tools;219
10.3.2;3.2. State-Based Testing;220
10.3.3;3.3. Invariant-Based Testing;223
10.3.4;3.4. Feedback-Directed Testing;225
10.3.5;3.5. Regression Testing;228
10.3.6;3.6. Cross-Browser Testing;228
10.3.7;3.7. Symbolic Execution and Concolic Testing;229
10.4;4. Test Oracles;231
10.5;5. Test Adequacy Assessment;233
10.5.1;5.1. Coverage;234
10.5.2;5.2. Fault-Finding Capability;234
10.5.3;5.3. Test-Case Robustness;236
10.6;6. Handling Failures;237
10.7;7. Programmer Support;238
10.8;8. Concluding Remarks;240
10.9;References;242
11;Author Index;248
12;Subject Index;258
13;Contents of Volumes in This Series;264

Leseproben

Chapter Two Advances in Behavior Modeling
Ella Roubtsova    Open University of the Netherlands, Heerlen, The Netherlands Abstract
This chapter provides a survey of existing approaches to discrete event behavior modeling. The comparison is based on the selected set of semantic elements useful for the major system life cycle activities, such as requirements engineering, analysis, system understanding, system design, and evolution. The semantic elements are identified in the observed approaches and illustrated with examples of models. The advantages of the semantic elements for the major system life cycle activities can be taken into account for the choice and for the design of behavior modeling approaches. The survey is based on a series of successful international workshops on behavior modeling run by the author and is enriched by the results of her research experience. Keywords Behavior models Semantics System life cycle activities Requirements engineering Analysis System understanding System design Evolution 1 Introduction
Modern software-based businesses are various and dynamic. E-commerce and E-procurement, Insurances, Mortgages, and E-education take a holistic approach, incorporate changeability of software to make a profit of it. As a result, the life cycle of businesses becomes similar to the software life cycle. The users, being the parts of interactive business processes, always propose new requirements. Most often, the requirements deal with changes in the system behavior. Behavior models serve to clarify what is wanted and how it can be integrated into the existing system. The competitors inspire analysis of success factors sometimes hidden in business processes. Analysis requires behavior models leading businesses to the business goals. Optimization of expenses drives the search for collaboration and services that are capable of implementing auxiliary subprocesses. However, the orchestration and choreography of collaborative businesses are fulfilled based on behavior models. With such tendencies, even daily business terminology, including key performance indicators and capability, cannot be fully understood without behavior models. The question is whether the available behavior modeling techniques are good enough for the challenges of the support of all activities of the system life cycle from requirements engineering, analysis, implementation to model-based testing (MBT), simulation, and reengineering? In order to answer this question in this chapter, we • formulate the properties of behavior modeling semantics needed for the major activities of the system life cycle support; • define common elements for separation of behavior models from other types of models, and the properties associated with combinations of elements with different semantics; • analyze the behavior modeling approaches inside the Unified Modeling Language (UML) and outside the UML and summarize the analysis in a table that relates the combinations of modeling semantics to the properties of behavior modeling approaches needed for the system life cycle support. The goal of the survey is to provide the semantic help for the choice or design of behavior modeling techniques for different activities of the system life cycle support. 2 Properties of the Modeling Semantics Needed for System Life Cycle Support
Any system, whether it be a business system or a software system or a combination of both, lives a spiral life cycle. Each turn of the spiral goes through the same stages of goal definitions, requirements gathering, design, analysis (simulation), implementation, and testing. After that, the system is maintained. When the new goals and requirements appear, the cycle is repeated. 1. Requirements engineering is a process of collecting of descriptions of desired system behavior. A requirement item always presents a part of behavior observed by a stakeholder from the stakeholder's perspective. Some of the requirements concern a localized domain; others crosscut many domains like the plumbing in a building across all its flats. In any case, a requirement represents a part of system behavior. The ability of the modeling technique to separate modeling of partial behavior simplifies interaction of stakeholders during modeling. Therefore, the desired property of the modeling technique is the ability to separate the modeling of partial behavior both for the localized and crosscutting concerns. 2. The design process is aimed to combine all partial descriptions and produce a system that meets the requirements. An ideal modeling method for design should allow composition of all the behavior models of requirements into the system model. 3. The analysis phase is aimed to validate the completeness of the design against the requirements. The adequate completeness can be validated by the execution of the model on different data. The result of the model execution is compared with the requirements. For this stage, the ideal behavior modeling method should be executable or, in other words, work with data. The semantics of the modeling techniques at the design phase should be comparable or easy transformable to the semantics of the modeling techniques used for the requirements engineering. During the comparison of the design model with the model of requirements, the tacit knowledge [1], hidden in the heads of users, often triggers new requirements so that the design is repeated until no more requirements are produced or until the deadline. If the semantics of the modeling techniques used for the requirements specification and the design are comparable, such a repetition of the design cycle demands less effort and time. 4. The implementation phase demands the modeling methods which reflect the restrictions of implementation platforms. Modern implementation platforms often do not support separation of concerns and their composition. The discrete event behavior modeling techniques used for modeling of the implementation reflect the implementation restrictions. The practice to apply the behavior modeling techniques reflecting implementation restrictions for modeling of business results in complex and not easily changeable models.
The implementation platforms evolve, and they will inevitably evolve to support smooth transformation of business models to implementation. Nowadays, however, the behavior modeling approaches need to propose traceable transformation to implementation models. The traceable transformation of executable behavior models to implementation leaves less room for errors because the models and implementation can be tested against requirements. 5. The testing phase is meant to check that the implementation corresponds to the requirements. The design level model is a very useful artifact for testing. It can even become the basis for the model-based automated testing. However, if the design phase produces a model with implementation details, then the model can cause error propagation in models both in the code and in the tests [2]. This means again that the traceability between the implementation model and the requirements models should be maintained. As we mentioned earlier, this activity has more precision when the model is executable. 6. The maintenance and evolution are also the activities of any system life cycle. These activities may be seen as analyses, requirements engineering, and design within the existing system. The composition property of behavior models eases the maintenance and evolution. If we summarize the requirements for the modeling techniques coming from all activities of the system life cycle support, we can make the following conclusion: the behavior modeling techniques supporting the whole system life cycle should enable 1. separation of modeling concerns gathered at the requirement phase; 2. composition of concerns modeled from requirements; 3. execution of the model of requirements for establishing relations between the model and the requirements and between the model and the implementation. In this survey, we analyze the semantic elements of behavior modeling approaches aiming to find how the semantic elements contribute to meeting the formulated above requirements. 3 Events, States, Transitions, and Communication–Composition
Discrete event behavior modeling techniques are all descendants of the finite-state machines (FSMs) (or finite-state automata) [3]. A finite-state machine FSM = (E, S, T) is an abstract machine,...