Automatic Synthesis of Component & Connector- Software Architectures with Bounded Combinatory Logic Dissertation zur Erlangung des Grades eines Doktors der Naturwissenschaften der Technischen Universit¨atDortmund an der Fakult¨atf¨urInformatik von Boris D¨udder Dortmund 2014 Tag der m¨undlichen Pr¨ufung: 25. August 2014 Dekan: Prof. Dr.-Ing. Gernot A. Fink Gutachter: Prof. Dr. Jakob Rehof Prof. Ph.D. Fritz Henglein Acknowledgment Foremost, I would like to express my sincere gratitude to my advisor Prof. Dr. Jakob Rehof for the continuous support of my dissertation and research, for his inspiration, patience, motivation, enthusiasm, and profound knowledge. His guidance helped me in all the time of my research and of writing of this thesis. I could not have imagined having a better advisor and mentor for my research and dissertation. Ditto, I would like to thank the rest of my promotions committee: Prof. Ph.D. Fritz Henglein, Prof. Dr. Bernhard Steffen, and Dr. Doris Schmed- ding, for their encouragement, insightful comments, and hard but constructive questions. My sincere thanks also goes to Dr. Moritz Martens, Prof. Dr. Dietmar Jan- nach, Prof. Dr. Pawe lUrzyczyn, Prof. Dr. Ugo de'Liguoro, Prof. Dr. Mari- angiola Dezani-Ciancaglini, Zani Sarkisya, Anna Vasileva, Jan Bessai, and Andrej Dudenhefner, for working with me on various exciting projects and also to Ute Joschko for her help. Thanks are also due to my wife Olga, my brother Gordon, and my parents. Abstract Combinatory logic synthesis is a new type-based approach towards auto- matic synthesis of software from components in a repository. In this thesis we show how the type-based approach can naturally be used to exploit taxonomic conceptual structures in software architectures and component repositories to enable automatic composition and configuration of components, and also code generation, by associating taxonomic concepts to architectural building blocks such as, in particular, software connectors. Components of a repository are exposed for synthesis as typed combinators, where intersection types are used to represent concepts that specify intended usage and functionality of a component. An algorithm for solving the type inhabitation problem in combinatory logic | does there exist a composition of combinators with a given type? | is then used to automate the retrieval, composition, and configuration of suitable building blocks with respect to a goal specification. Since type inhabitation has high computational complexity, heuristic opti- mizations for the inhabitation algorithm are essential for making the approach practical. We discuss particularly important (theoretical and pragmatic) opti- mization strategies and evaluate them by experiments. Furthermore, we apply this synthesis approach to define a method for software connector synthesis for realistic software architectures based on a type theoretic model. We conduct experiments with a rapid prototyping tool that employs this method on complex concrete ERP- and e-Commerce-systems and discuss the results. Contents 1 Introduction 1 1.1 Composition Synthesis and Inhabitation . .3 1.2 Combinatory Logic Synthesis . .5 1.3 Example for Combinatory Logic Synthesis . .7 1.4 Combinatory Logic Synthesis and Software Connectors . .9 1.5 Why does this problem matter? . 12 1.6 Synthesizing from Components . 13 1.7 Contributions . 13 1.7.1 Publications & Delimitations . 13 1.7.2 Theoretical Contributions . 15 1.7.3 Technical Contributions . 15 1.7.4 Interconnections between Contributions . 16 1.8 Organization . 17 2 Software Architecture 19 2.1 What is Software Architecture? . 19 2.2 Describing Software Architectures . 21 2.2.1 Components and Connectors . 22 2.2.2 Software Connector Roles . 28 2.2.3 Software Interconnection Models . 29 2.2.4 Composing Basic Connectors . 30 2.3 Synthesizing Software Architectures . 31 2.4 Ontologies in Software Architecture . 31 3 Bounded Combinatory Logic 33 3.1 Combinatory Logic . 33 3.2 Intersection Types . 35 3.2.1 Types . 36 3.2.2 Subtyping . 36 3.2.3 Paths . 38 3.2.4 Substitutions . 39 i ii CONTENTS 3.3 Bounded Combinatory Logic . 39 3.3.1 Type Assignment . 40 3.3.2 Relativized Inhabitation Problem . 41 3.4 Alternating Turing Machines . 43 3.5 Deciding Relativized Inhabitation . 44 3.6 Combinatory Logic Synthesis . 46 3.7 Related Work on Synthesis . 47 4 Optimization of CLS 51 4.1 Theoretical Algorithm . 52 4.1.1 Restricting Intersections in Substitutions . 52 4.1.2 Intersection Type Matching . 56 4.1.3 Matching Optimization . 59 4.1.4 Lookahead Optimization . 61 4.1.5 Experimental Evaluation . 66 4.2 Algorithmic Optimization . 71 4.2.1 Execution Graph . 72 4.2.2 Term Level Optimization . 77 4.2.3 Elimination of Redundant Calculations . 80 4.2.4 Parallel Computation . 87 4.3 A Distributed Algorithm for BCL0(\; ≤) Inhabitation . 94 5 Combinatory Logic Synthesizer 105 5.1 Reconstructing Inhabitants . 105 5.2 Implementation . 106 5.3 (CL)S Input Specification . 110 5.4 (CL)S Output Specification . 112 5.5 Additional Applications and Extensions . 115 6 Synthesis of Software Architectures 119 6.1 Software Connectors . 119 6.2 Type-theoretic Model . 120 6.2.1 Component . 120 6.2.2 Connector . 121 6.2.3 Building Blocks . 122 6.2.4 C&C Type Environment . 125 6.2.5 Taxonomy . 126 6.3 Combinatory Logic Connector Synthesis . 134 6.3.1 Synthesis of Connector . 134 6.3.2 Generation of a Connector . 135 6.3.3 Combinatory Logic Connector Synthesis Method . 136 CONTENTS iii 6.3.4 Example for Combinatory Logic Connector Synthesis . 136 6.3.5 Synthesis of Behavior . 138 6.3.6 Designing C&C Type Repositories and Templates . 139 6.4 Related Work . 143 7 ArchiType 147 7.1 UML2 Extension . 148 7.2 User Interface . 149 7.3 Synthesizing Connectors in UML2 . 150 7.4 Code Generation . 152 7.5 ArchiType Composition Language . 154 7.6 Staged Composition Synthesis . 159 7.6.1 Implementation Type Correctness . 161 7.7 Implementation . 162 7.8 Related Work . 164 8 Applications and Experiments 165 8.1 Secure Connectors . 166 8.1.1 Setup . 166 8.1.2 Execution of the Experiment . 166 8.1.3 Results . 167 8.1.4 Analysis and Discussion . 169 8.2 Detailed Broker Pattern Example . 170 8.2.1 Setup . 170 8.2.2 Execution . 173 8.2.3 Results, Analysis, and Discussion . 173 8.3 Enterprise Resource Planning Scenario . 174 8.3.1 Setup . 174 8.3.2 Execution . 175 8.3.3 Results . 179 8.4 e-Commerce Scenario . 179 8.4.1 Setup . 180 8.4.2 Execution . 180 8.4.3 Results . 188 8.4.4 Analysis and Discussion . 188 8.5 Collective Analysis and Discussion . 189 8.5.1 Expressiveness . 189 8.5.2 Applicability . 190 8.5.3 Adaptability . 190 8.5.4 Costs and Effort . 191 8.5.5 Usability . 192 iv CONTENTS 8.5.6 Limitations . 193 9 Conclusion 197 A Selected implementation details 199 A.1 Grammar of (CL)S's input language . 199 A.2 Example in the Listing in ArchiType CL . 201 A.3 Example Template in T4 . 202 A.4 Algorithm Listings . 205 A.4.1 Inhabitation Algorithm (data-centric part) . 205 B Experiments 207 B.1 Compiler . 207 B.1.1 Compiler Flags . 207 B.2 Benchmark Problems . 207 B.3 Configuration of the Test Systems . 209 B.3.1 Test System I - Desktop PC . 209 B.3.2 Test System II - Compute Server . 209 Acronyms 211 List of Figures 215 List of Tables 219 List of Algorithms 221 Bibliography 223 Index 241 Chapter 1 Introduction Software systems tend to be large and complex. These factors must be managed in the design and development of such systems. Except for product lines, software architectures are unique products. Design and development take the form of a project and the development process is repeated for every software system that is constructed. Over the years, software engineers designed and developed software appli- cations and -systems with increasing complexity. Different techniques have been developed to handle growing complexity of systems. A very powerful tool is the abstraction of a system's building blocks. The very low-level abstraction of functions in procedural programming was replaced by objects in object-oriented programming. From there, objects have been abstracted to distributed programming and after that to component-based programming. The idea of component-based programming is to divide software applications and -systems into reusable components. The advantage of reusable compo- nents is that the number of newly created components for a new application can be reduced by reusing existing components. That means that components only have to be developed for missing functionality that is not covered by existing components. The idea of component marketplaces emerged where components are traded. Furthermore, topically coherent components have been bundled into libraries or repositories in order to increase revenue for producers of such repositories and also to increase additional benefit for users of component repositories. In order to develop a component-based software application or -system suitable components have to be retrieved from a suitable component repository and composed or assembled in a way such that the composite application fulfills the functional and non-functional requirements demanded bythe end-user. 1 2 CHAPTER 1. INTRODUCTION As it turned out, it was not that easy to compose components in a goal- directed fashion. Components are typically documented in textual form. The sheer quantity of components that have to be used to compose the intended software application made such an approach intricate and error-prone. From this problem, the idea emerged to automate composition by synthesizing a composition plan describing which components have to be composed with other components to reach a specific synthesis goal. Component-oriented synthesis is the goal-directed construction of a composite software system composed by components residing in a component repository.