E-Book, Englisch, 185 Seiten
Nanz The Future of Software Engineering
1. Auflage 2010
ISBN: 978-3-642-15187-3
Verlag: Springer
Format: PDF
Kopierschutz: 1 - PDF Watermark
E-Book, Englisch, 185 Seiten
ISBN: 978-3-642-15187-3
Verlag: Springer
Format: PDF
Kopierschutz: 1 - PDF Watermark
This book focuses on defining the achievements of software engineering in the past decades and showcasing visions for the future. It features a collection of articles by some of the most prominent researchers and technologists who have shaped the field: Barry Boehm, Manfred Broy, Patrick Cousot, Erich Gamma, Yuri Gurevich, Tony Hoare, Michael A. Jackson, Rustan Leino, David L. Parnas, Dieter Rombach, Joseph Sifakis, Niklaus Wirth, Pamela Zave, and Andreas Zeller. The contributed articles reflect the authors' individual views on what constitutes the most important issues facing software development. Both research- and technology-oriented contributions are included. The book provides at the same time a record of a symposium held at ETH Zurich on the occasion of Bertrand Meyer's 60th birthday.
Sebastian Nanz is a postdoctoral researcher at ETH Zurich, with main interests in concurrency, programming languages, and verification. He graduated with M.Sc. degrees in computer science and mathematics from Technische Universität München in 2002 and 2004, and obtained his Ph.D. degree in computer science from Imperial College London in 2006. Before joining ETH Zurich in 2009, he also worked as a researcher at the Technical University of Denmark, Microsoft Research Cambridge, and Yale University.
Autoren/Hrsg.
Weitere Infos & Material
1;Preface;4
2;Table of Contents;5
3;Some Future Software Engineering Opportunities andChallenges;6
3.1;1 Introduction;6
3.2;2 Future Software Engineering Opportunities and Challenges;7
3.2.1;2.1 Increasing emphasis on rapid development and adaptability;7
3.2.2;2.2 Increasing Criticality and Need for Assurance;9
3.2.2.1;2.2.1 An Incremental Development Process for Achieving Both Agility andAssurance;10
3.2.3;2.3 Increased complexity, global systems of systems, and need for scalabilityand interoperability;12
3.2.4;2.4 Increased needs to accommodate COTS, software services, and legacysystems;13
3.2.5;2.5 Increasingly large volumes of data and ways to learn from them;15
3.2.6;2.6 Increased emphasis on users and end value;17
3.2.6.1;2.6.1 Systems and Software Engineering Process Implications;17
3.2.7;2.7 Computational Plenty and Multicore Chips;19
3.2.8;2.8 Increasing Integration of Software and Systems Engineering;20
3.2.8.1;2.8.1 Systems and Software Engineering Process Implications;21
3.2.9;2.9 Wild Cards: Autonomy and Bio-Computing;22
3.3;3 A Scalable Spiral Process Model for 21st Century Systems andSoftware;23
3.3.1;3.1 21st Century System and Software Development and Evolution Modes;23
3.3.2;3.2 Overview of the Incremental Commitment Spiral Model;24
3.3.2.1;3.2.1 Other Views of the Incremental Commitment Spiral Model (ICSM);26
3.3.2.1.1;3.2.2 Underlying ICSM Principles;29
3.3.2.1.2;3.2.3 Model Experience to Date;30
3.4;4 Implications for 21st Century Enterprise Processes;31
3.4.1;4.1 Adaptive vs. Purchasing-Agent Acquisition;31
3.4.2;4.2 Human Relations;32
3.5;5 Conclusions;33
3.6;References;34
4;Seamless Method- and Model-based Software andSystems Engineering;38
4.1;1 Motivation;38
4.2;2 Engineering Software Intensive Systems;39
4.2.1;2.1 Engineering and Modelling based on First Principles;39
4.2.2;2.2 From Principles to Methods, from Methods to Processes;40
4.2.2.1;2.2.1 Key Steps in Software and Systems Engineering;40
4.2.2.2;2.2.2 Requirements Engineering;41
4.2.2.3;2.2.3 Architecture Design;41
4.2.3;2.3 Empirical and Experimental Evaluation of Software Engineering Principlesand Methods;42
4.2.3.1;2.3.1 Justifying Claims about Principles and Methods;42
4.2.4;3 Scientific Foundations of Engineering Methods;43
4.2.4.1;3.1 About the Concept of Engineering Methods;43
4.2.4.2;3.2 Why Formal Specification and Verification is Not Enough;43
4.2.4.3;3.3 Importance of the Formalization of Engineering Concepts;43
4.2.4.4;3.4 The Role of Automation and Tools;44
4.2.5;4 Seamless Model Based Development;44
4.2.5.1;4.1 What are Helpful Models?;44
4.2.5.1.1;4.1.1 Modelling Requirements;44
4.2.5.1.2;4.1.2 Modelling Architecture;45
4.2.5.1.3;4.1.3 From Requirements and Architecture to Implementation and Integration;45
4.2.5.2;4.2 Modelling Systems;46
4.2.5.2.1;4.2.1 The Significance of Precise Terminology and Clean System Concepts;46
4.2.5.2.2;4.2.2 An Integrated Model for System Specification and Implementation;46
4.2.5.2.3;4.2.3 From Models to Code;47
4.2.5.2.4;4.2.4 Software product lines;47
4.2.5.2.5;4.2.5 Modular System Design, Specification, and Implementation;48
4.2.5.2.6;4.2.6 Formal Foundation of Methods and Models;49
4.2.6;5 Seamless Modelling;49
4.2.6.1;5.1 Integration of Modelling Techniques;49
4.2.6.2;5.2 Reducing Costs – Increasing Quality;50
4.2.7;6 Software Project Governance;50
4.2.8;7 Concluding Remarks: Towards a Synergy between FormalMethods and Model Based Development;51
4.2.8.1;References;51
5;Logical Abstract Domains and Interpretations;53
5.1;1 Introduction;53
5.2;2 Terminology on First-Order Logics, Theories, Interpretations and Models;54
5.2.1;2.1 First-order logics;54
5.2.2;2.2 Theories;55
5.2.3;2.3 Interpretations;55
5.2.4;2.4 Models;56
5.2.5;2.5 Satisfiability and validity (modulo interpretations and theory);56
5.2.6;2.6 Decidable theories;57
5.2.7;2.7 Comparison of theories;59
5.3;3 Terminology on Abstract Interpretation;59
5.3.1;3.1 Interpreted concrete semantics;59
5.3.2;3.2 Abstract domains;60
5.3.3;3.3 Abstract semantics;61
5.3.4;3.4 Soundness of abstract domains;61
5.3.5;3.5 Soundness of abstract semantics;62
5.3.6;4 Abstraction of Multi-Interpreted Concrete Semantics;62
5.3.6.1;4.1 Multi-interpreted semantics;62
5.3.6.2;4.2 Abstractions between multi-interpretations;63
5.3.6.3;4.3 Uniform abstraction of interpretations;64
5.3.6.4;4.4 Abstraction by a theory;65
5.3.7;5 Uninterpreted Axiomatic Semantics;65
5.3.8;6 Axiomatic Semantics Modulo Interpretations;67
5.3.8.1;6.1 Universal interpretation of the axiomatic semantics;67
5.3.8.2;6.2 Adding more precision: axiomatic semantics modulo interpretations;68
5.3.8.3;6.3 Axiomatic Semantics Modulo Theory;68
5.3.8.4;6.4 Interpreted assignment;69
5.3.9;7 Logical Abstract Domains;69
5.3.9.1;7.1 Abstraction to Logical Abstract Domains;70
5.3.9.2;7.2 Logical abstract transformers;71
5.3.9.3;7.3 Widening and narrowing;72
5.3.10;8 Soundness of Unsound Abstractions;73
5.3.11;9 Conclusion;73
5.3.12;References;74
6;Design Patterns – Past, Present & Future;77
7;Evidential Authorization?;78
7.1;1 Introduction;79
7.2;2 Clinical Trials Scenario, Informal Description;81
7.2.1;2.1 Background;81
7.2.2;2.2 Policies;82
7.3;3 The World of One DKAL Principal;83
7.3.1;3.1 Substrate Functions and Infon Relations;85
7.3.2;3.2 Notational Conventions;86
7.3.3;3.3 Disclaimer;87
7.4;4 Substrate;87
7.4.1;4.1 Canonic Names, and Term Evaluation;88
7.4.2;4.2 Roster;89
7.5;5 Logic;89
7.5.1;5.1 Infons;89
7.5.2;5.2 Infons as formulas;90
7.5.3;5.3 Logics and Theories;91
7.5.4;5.4 Justifications;92
7.5.5;6 Infostrate;93
7.5.5.1;6.1 Knowledge;93
7.5.5.2;6.2 Communication;94
7.5.5.3;6.3 Filters;97
7.5.6;7 Clinical Trial Scenario: Policies;98
7.5.6.1;7.1 Policy of Org1;99
7.5.6.2;7.2 Policy of Site1;100
7.5.6.3;7.3 Policy of Phys1;101
7.5.6.4;7.4 Policy of KeyManager;102
7.5.7;8 Future work;103
7.5.8;References;104
8;Engineering and Software Engineering;105
8.1;1 Software Engineering Is about Dependability;105
8.2;2 A Software Engineer’s Product Is Not the Software;106
8.3;3 The Software and Its Problem World Are Inseparable;107
8.4;4 A Computer-Based System Is a Contrivance in the World;108
8.5;5 General Laws and Specific Contrivances;108
8.6;6 The Lesson of the Established Branches;110
8.7;7 Specialisation Has Many Dimensions;111
8.8;8 The Key to Dependability Is Artifact Specialisation;111
8.9;9 Normal and Radical Design;112
8.10;10 Artifact Specialisations in Software Engineering;114
8.11;11 Artifact Specialisation Needs Visible Exemplars;115
8.12;12 The Challenge of Software System Structures;116
8.13;13 Forgetting the Importance of Structure;117
8.14;References;118
9;Tools and Behavioral Abstraction: A Direction for Software Engineering;120
9.1;0 Introduction;120
9.2;1 Composing Programs;121
9.3;2 A Development Environment for Behavioral Abstraction;124
9.4;3 Challenges;126
9.5;4 Related Work and Acknowledgments;127
9.6;5 Conclusion;128
9.7;References;128
10;Precise Documentation: The Key to Better Software;130
10.1;1 Documentation: a perpetually unpopular topic;130
10.2;2 Types of documents;131
10.2.1;2.1 Programming vs. software design;131
10.2.2;2.2 What is a document?;132
10.2.3;2.3 Are computer programs self-documenting?;133
10.2.4;2.4 Internal documentation vs. separate documents;133
10.2.5;2.5 Models vs. documents;134
10.2.6;2.6 Design documents vs. introductory documentation;134
10.2.7;2.7 Specifications vs. other descriptions;135
10.2.8;2.8 Extracted documents;136
10.2.9;3 Roles played by documents in development;137
10.2.9.1;3.1 Design through documentation;137
10.2.9.2;3.2 Documentation based design reviews;137
10.2.9.3;3.3 Documentation based code inspections;137
10.2.9.4;3.4 Documentation based revisions;137
10.2.9.5;3.5 Documentation in contracts;138
10.2.9.6;3.6 Documentation and attributing blame;138
10.2.9.7;3.7 Documentation and compatibility;138
10.2.10;4 Costs and benefits of software documentation;138
10.2.11;5 Considering readers and writers;140
10.2.12;6 What makes design documentation good?;141
10.2.12.1;6.1 Accuracy;141
10.2.12.2;6.2 Unambiguous;141
10.2.12.3;6.3 Completeness;142
10.2.12.4;6.4 Ease of access;142
10.2.13;7 Documents and mathematics;142
10.2.13.1;7.1 Documents are predicates;142
10.2.13.2;7.2 Mathematical definitions of document contents;143
10.2.13.3;7.3 Using mathematics in documents;143
10.2.14;8 The most important software design documents;143
10.2.14.1;8.1 Requirements documentation;144
10.2.14.2;8.2 Software component interface documents;146
10.2.14.3;8.3 Program function documents;147
10.2.14.4;8.4 Module internal design documents;147
10.2.14.5;8.5 Documenting nondeterminism;148
10.2.14.6;8.6 Additional documents;148
10.2.15;9 Tabular expressions for documentation;149
10.2.16;10 Summary and Outlook;151
10.2.17;References;151
11;Empirically Driven Software Engineering Research;154
12;Component-based Construction of Heterogeneous Real-time Systems in BIP;155
13;Computer Science: A Historical Perspective and a Current Assessment;156
14;Internet Evolutionand the Role of Software Engineering;157
14.1;1 Introduction;157
14.2;2 The “classic” Internet architecture;158
14.3;3 The real Internet;160
14.3.1;3.1 Network management and operations;160
14.3.2;3.2 Middleboxes;160
14.3.3;3.3 Network and transport layers;161
14.3.4;3.4 Middleware and applications;163
14.3.5;3.5 Principles and priorities;164
14.4;4 Internet trends and evolution;166
14.4.1;4.1 Trends in practical networking;166
14.4.2;4.2 Trends in networking research;166
14.4.3;4.3 Prospects for evolution;167
14.5;5 A pattern for network architecture;168
14.5.1;5.1 Definition of an overlay;168
14.5.2;5.2 Private subnetworks;169
14.5.3;5.3 Mobility and multihoming;170
14.5.4;5.4 Overlay composition;171
14.6;6 Research challenges, from the top down;172
14.6.1;6.1 Overlay organization;172
14.6.2;6.2 Overlay interaction;172
14.6.3;6.3 Communication primitives;173
14.6.4;6.4 Security;174
14.7;7 Conclusions;175
14.8;Acknowledgment;175
14.9;References;175
15;Mining Specifications: A Roadmap;178
15.1;1 Introduction;178
15.2;2 The Problem;180
15.3;3 Mining Programs;181
15.4;4 Learning from Usage;183
15.5;5 A Hierarchy of Abstractions;184
15.6;6 Conclusion and Consequences;185
15.7;References;187
16;Greetings to Bertrand on the Occasion of his Sixtieth Birthday;188
17;Author Index;190




