Software Technology

Mike Hinchey, PhD, is a Professor and former Director of Lero - the Irish Software Research Centre at the University of Limerick, Ireland. Dr. Hinchey is also the President of the International Federation for Information Processing (IFIP), a former column editor for Software Technologies (IEEE Computer Magazine), and a senior member of the IEEE. He is the author of more than 200 papers, and has written multiple books.

• Foreword xvPreface xixAcknowledgments xxiiiList of Contributors xxvPart I The Software Landscape 11 Software Crisis 2.0 3Brian Fitzgerald1.1 Software Crisis 1.0 31.2 Software Crisis 2.0 51.2.1 Hardware Advances 61.2.2 “Big Data” 81.2.3 Digital Natives Lifelogging and the Quantified Self 91.2.4 Software-Defined∗ 101.3 Software Crisis 2.0: The Bottleneck 101.3.1 Significant Increase in Volume of Software Required 111.3.2 New Skill Sets Required for Software Developers 121.4 Conclusion 13References 142 Simplicity as a Driver for Agile Innovation 17Tiziana Margaria and Bernhard Steffen2.1 Motivation and Background 172.2 Important Factors 202.3 The Future 222.4 Less Is More: The 80/20 Principle 272.5 Simplicity: A Never Ending Challenge 282.6 IT Specifics 292.7 Conclusions 29Acknowledgments 30References 303 Intercomponent Dependency Issues in Software Ecosystems 35Maëlick Claes, Alexandre Decan, and Tom Mens3.1 Introduction 353.2 Problem Overview 363.2.1 Terminology 363.2.2 Identifying and Retrieving Dependency Information 383.2.3 Satisfying Dependencies and Conflicts 393.2.4 Component Upgrade 403.2.5 Inter-Project Cloning 413.3 First Case Study: Debian 423.3.1 Overview of Debian 423.3.2 Aggregate Analysis of Strong Conflicts 443.3.3 Package-Level Analysis of Strong Conflicts 453.4 Second Case Study: The R Ecosystem 463.4.1 Overview of R 463.4.2 R Package Repositories 473.4.3 Interrepository Dependencies 503.4.4 Intrarepository Dependencies 523.5 Conclusion 53Acknowledgments 54References 544 Triangulating Research Dissemination Methods: A Three-Pronged Approach to Closing the Research–Practice Divide 58Sarah Beecham, Ita Richardson, Ian Sommerville, Padraig O’Leary, Sean Baker, and John Noll4.1 Introduction 584.2 Meeting the Needs of Industry 604.2.1 Commercialization Feasibility Study 614.2.2 Typical GSE Issues Were Reported 624.3 The Theory–Practice Divide 634.3.1 Making Research Accessible 644.3.2 Where Do Practitioners Really Go for Support? 654.4 Solutions: Rethinking Our Dissemination Methods 664.4.1 Workshops, Outreach, and Seminars 664.4.2 Case Studies 694.4.3 Action Research 704.4.4 Practitioner Ph.D.’s 714.4.5 Industry Fellowships 734.4.6 Commercializing Research 744.5 Obstacles to Research Relevance 764.5.1 The (IR) Relevance of Academic Software Engineering Research 764.5.2 Barriers to Research Commercialization 774.5.3 Academic Barriers to Commercialization 784.5.4 Business Barriers to Commercialization 794.5.5 Organizational Barriers to Commercialization 804.5.6 Funding Barriers to Commercialization 814.6 Conclusion 844.6.1 Research and Practice Working Together to Innovate 854.6.2 Final Thoughts 86Acknowledgments 86References 86Part II Autonomous Software Systems    915 Apoptotic Computing: Programmed Death by Default for Software Technologies 93Roy Sterritt and Mike Hinchey5.1 Biological Apoptosis 935.2 Autonomic Agents 945.3 Apoptosis within Autonomic Agents 965.4 NASA SWARM Concept Missions 985.5 The Evolving State-of-the-Art Apoptotic Computing 1005.5.1 Strong versus Weak Apoptotic Computing 1005.5.2 Other Research 1015.6 “This Message Will Self-Destruct”: Commercial Applications 1025.7 Conclusion 102Acknowledgments 103References 1036 Requirements Engineering for Adaptive and Self-Adaptive Systems 107Emil Vassev and Mike Hinchey6.1 Introduction 1076.2 Understanding ARE 1086.3 System Goals and Goals Models 1096.4 Self-∗ Objectives and Autonomy-Assistive Requirements 1116.4.1 Constraints and Self-∗ Objectives 1136.4.2 Mission Analysis and Self-∗ Objectives 1146.5 Recording and Formalizing Autonomy Requirements 1166.5.1 ARE Requirements Chunk 1176.6 Conclusion 118Acknowledgments 119References 1197 Toward Artificial Intelligence through Knowledge Representation for Awareness 121Emil Vassev and Mike Hinchey7.1 Introduction 1217.2 Knowledge Representation 1227.2.1 Rules 1227.2.2 Frames 1227.2.3 Semantic Networks and Concept Maps 1227.2.4 Ontologies 1237.2.5 Logic 1237.2.6 Completeness and Consistency 1247.2.7 Reasoning 1257.2.8 Technologies 1257.3 KnowLang 1267.3.1 Modeling Knowledge with KnowLang 1277.3.2 Knowledge Representation for Self-Adaptive Behavior 1297.3.3 Case Study 1297.4 Awareness 1317.4.1 Classes of Awareness 1327.4.2 Structuring Awareness 1337.4.3 Implementing Awareness 1347.5 Challenges and Conclusion 136References 136Part III Software Development and Evolution 1398 Continuous Model-Driven Engineering 141Tiziana Margaria, Anna-Lena Lamprecht, and Bernhard Steffen8.1 Introduction 1418.2 Continuous Model-Driven Engineering 1438.3 CMDE in Practice 1478.4 Conclusion 150Acknowledgment 150References 1519 Rethinking Functional Requirements: A Novel Approach Categorizing System and Software Requirements 155Manfred Broy9.1 Introduction 1559.2 Discussion: Classifying Requirements – Why and How 1589.2.1 On Classifying Requirements as Being Functional 1589.2.2 “Nonfunctional” Requirements and Their Characterization 1599.2.3 Limitations of Classification Due to Heterogeneity and Lacking Precision 1609.2.4 Approach: System Model-Based Categorization of Requirements 1629.3 The System Model 1649.3.1 The Basics: System Modeling Ontology 1649.3.2 System Views and Levels of Abstractions 1719.3.3 Structuring Systems into Views 1729.4 Categorizing System Properties 1729.4.1 System Behavior: Behavioral Properties 1739.4.2 Variations in Modeling System Behavior 1759.4.3 System Context: Properties of the Context 1769.4.4 Nonbehavioral System Properties: System Representation 1779.5 Categorizing Requirements 1789.5.1 A Rough Categorization of Requirements 1799.5.2 A Novel Taxonomy of Requirements? 1839.6 Summary 186Acknowledgments 187References   18710 The Power of Ten—Rules for Developing Safety Critical Code 188Gerard J. Holzmann10.1 Introduction 18810.2 Context 18910.3 The Choice of Rules 19010.4 Ten Rules for Safety Critical Code 19210.5 Synopsis 200References 20111 Seven Principles of Software Testing 202Bertrand Meyer11.1 Introduction 20211.2 Defining Testing 20211.3 Tests and Specifications 20311.4 Regression Testing 20411.5 Oracles 20411.6 Manual and Automatic Test Cases 20511.7 Testing Strategies 20511.8 Assessment Criteria 20611.9 Conclusion 207References 20712 Analyzing the Evolution of Database Usage in Data-Intensive Software Systems 208Loup Meurice, Mathieu Goeminne, Tom Mens, Csaba Nagy, Alexandre Decan, and Anthony Cleve12.1 Introduction 20812.2 State of the Art 21012.2.1 Our Own Research 21112.3 Analyzing the Usage of ORM Technologies in Database-Driven Java Systems 21212.4 Coarse-Grained Analysis of Database Technology Usage 21512.4.5 Discussion 22212.5 Fine-Grained Analysis of Database Technology Usage 22212.5.1 Analysis Background 22212.5.2 Conceptual Schema 22412.5.3 Metrics 22612.5.4 Discussion 23512.6 Conclusion 23612.7 Future Work 237Acknowledgments 238References 238Part IV Software Product Lines and Variability 4113 Dynamic Software Product Lines 243Svein Hallsteinsen, Mike Hinchey, Sooyong Park, and Klaus Schmid13.1 Introduction 24313.2 Product Line Engineering 24313.3 Software Product Lines 24413.4 Dynamic SPLs 245References 24614 Cutting-Edge Topics on Dynamic Software Variability 247Rafael Capilla, Jan Bosch, and Mike Hinchey14.1 Introduction 24714.2 The Postdeployment Era 24814.3 Runtime Variability Challenges Revisited 24914.4 What Industry Needs from Variability at Any Time? 25314.5 Approaches and Techniques for Dynamic Variability Adoption 25514.6 Summary 26614.7 Conclusions 267References 268Part V Formal Methods 27115 The Quest for Formal Methods in Software Product Line Engineering 273Reiner Hähnle and Ina Schaefer15.1 Introduction 27315.2 SPLE: Benefits and Limitations 27415.3 Applying Formal Methods to SPLE 27515.4 The Abstract Behavioral Specification Language 27715.5 Model-Centric SPL Development with ABS 27915.6 Remaining Challenges 28015.6.4 Maintenance 28015.7 Conclusion 281References 28116 Formality, Agility, Security, and Evolution in Software Engineering 282Jonathan P. Bowen, Mike Hinchey, Helge Janicke, Martin Ward, and Hussein Zedan16.1 Introduction 28216.2 Formality 28316.3 Agility 28316.4 Security 28416.5 Evolution 28516.6 Conclusion 289Acknowledgments 290References 290Part VI Cloud Computing 29317 Cloud Computing: An Exploration of Factors Impacting Adoption 295Lorraine Morgan and Kieran Conboy17.1 Introduction 29517.2 Theoretical Background 29617.3 Research Method 29817.4 Findings and Analysis 30317.4.2 Organizational Factors Impacting Adoption 30617.4.3 Environmental Factors Impacting Adoption 30817.5 Discussion and Conclusion 31017.5.1 Limitations and Future Research 311References 31118 A Model-Centric Approach to the Design of Resource-Aware Cloud Applications 315Reiner Hähnle and Einar Broch Johnsen18.1 Capitalizing on the Cloud 31518.2 Challenges 31618.2.1 Empowering the Designer 31618.2.2 Deployment Aspects at Design Time 31618.3 Controlling Deployment in the Design Phase 31818.4 ABS: Modeling Support for Designing Resource-Aware Applications 31918.5 Resource Modeling with ABS 32018.6 Opportunities 32418.6.1 Fine-Grained Provisioning 32418.6.2 Tighter Provisioning 32418.6.3 Application-Specific Resource Control 32418.6.4 Application-Controlled Elasticity 32418.7 Summary 325Acknowledgments 325References 325Index 327