Software Architecture: 14th European Conference, ECSA 2020, L'Aquila, Italy, September 14–18, 2020, Proceedings [1st ed.] 9783030589226, 9783030589233

Citation preview

LNCS 12292

Anton Jansen · Ivano Malavolta · Henry Muccini · Ipek Ozkaya · Olaf Zimmermann (Eds.)

Software Architecture 14th European Conference, ECSA 2020 L’Aquila, Italy, September 14–18, 2020 Proceedings

Lecture Notes in Computer Science Founding Editors Gerhard Goos Karlsruhe Institute of Technology, Karlsruhe, Germany Juris Hartmanis Cornell University, Ithaca, NY, USA

Editorial Board Members Elisa Bertino Purdue University, West Lafayette, IN, USA Wen Gao Peking University, Beijing, China Bernhard Steffen TU Dortmund University, Dortmund, Germany Gerhard Woeginger RWTH Aachen, Aachen, Germany Moti Yung Columbia University, New York, NY, USA

12292

More information about this series at http://www.springer.com/series/7408

Anton Jansen Ivano Malavolta Henry Muccini Ipek Ozkaya Olaf Zimmermann (Eds.) •

•

•

•

Software Architecture 14th European Conference, ECSA 2020 L’Aquila, Italy, September 14–18, 2020 Proceedings

123

Editors Anton Jansen Koninklijke Philips N.V. Eindhoven, The Netherlands

Ivano Malavolta VU Amsterdam Amsterdam, The Netherlands

Henry Muccini University of L’Aquila L’Aquila, Italy

Ipek Ozkaya Carnegie Mellon University Pittsburg, PA, USA

Olaf Zimmermann University of Applied Sciences of Eastern Switzerland Rapperswil, Switzerland

ISSN 0302-9743 ISSN 1611-3349 (electronic) Lecture Notes in Computer Science ISBN 978-3-030-58922-6 ISBN 978-3-030-58923-3 (eBook) https://doi.org/10.1007/978-3-030-58923-3 LNCS Sublibrary: SL2 – Programming and Software Engineering © Springer Nature Switzerland AG 2020 This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publisher, the authors and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations. This Springer imprint is published by the registered company Springer Nature Switzerland AG The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland

Preface

The European Conference on Software Architecture (ECSA) is the premier European conference that provides researchers and practitioners with a platform to present and discuss the most recent, innovative, and significant findings and experiences in the field of software architecture research and practice. This 14th edition of ECSA builds upon a series of successful European workshops on software architecture held during 2004–2006, as well as a series of European software architecture conferences during 2007–2019. This edition of ECSA had a unique nature as due to the novel coronavirus, COVID-19, it was the first ECSA conference that was originally to be held in L’Aquila, Italy, but convened the participants around the globe virtually during September 14–18, 2020. This year’s technical program included a main research track, three keynote talks, and an industry track (included in this volume), as well as a doctoral symposium track with its own keynote, a gender diversity in software architecture track with its own keynote, and a tool demos track. In addition, ECSA 2020 also offered nine workshops on diverse topics related to the software architecture discipline, such as automotive architectures, quality-aware DevOps, and IoT systems. In addition, ECSA 2020 featured a journal first track partnering with the Journal of Software and Systems, Elsevier, and the IEEE Software Magazine. The contributions of all these other meetings are included in the companion proceedings, published in a volume by Springer CCIS. ECSA 2020 received 103 contributions to all tracks. For the main research track, we received 60 submissions in the two main categories: full and short research papers. Based on the recommendations of the Program Committee, we accepted 12 papers as full papers and 5 additional papers as short papers. Hence the acceptance rate for full research papers was 20% for ECSA 2020. For the industrial track, we received 11 submissions and accepted 6 of them. The conference attracted papers (co-)authored by researchers, practitioners, and academia from 24 countries (Austria, Australia, Brazil, Canada, Chile, Columbia, Denmark, Ecuador, Finland, France, Germany, Italy, the Netherlands, New Zealand, Spain, Pakistan, Poland, Portugal, Romania, Sweden, Switzerland, Tunisia, the UK, and the USA). The main ECSA program had three keynotes. Professor Ivica Crnkovic from Chalmers University, Sweden, talked about “AI engineering—new challenges in system and software architecting and managing lifecycle for AI-based systems.” Professor Diomidis Spinellis, from Athens University of Economics and Business, Greece, gave a presentation on “Fifty years of sustained progress: Form, forces, and lessons of Unix architectural evolution.” The industry keynote was delivered by Michael Keeling, an experienced software engineer and the author of the book “Design It! From Programmer to Software Architect.” We are grateful to the members of the Program Committee for helping us to seek submissions and provide valuable and timely reviews. Their efforts enabled us to put together a high-quality technical program for ECSA 2020. We would like to thank the

vi

Preface

members of the Organizing Committee of ECSA 2020 for playing an enormously important role in successfully organizing the event with several tracks and collocated events, as well as the workshop organizers, who made significant contributions to this year’s successful event. We also thank our sponsors who provided financial support for the event: the University of L’Aquila, Italy, provided the technology infrastructure and the support needed, nExpecto, and Springer. The ECSA 2020 submission and review process was supported by the EasyChair conference management system. We acknowledge the prompt and professional support from Springer who published these proceedings in electronic volumes as part of the Lecture Notes in Computer Science series. Finally, we would like to thank the authors of all the ECSA 2020 submissions and the attendees of the conference for their participation. ECSA 2020 planning and execution took place during an unprecedented time in our history, globally we had to face a pandemic as well as understand and react to consequences of systematic racism and intolerance. As the ECSA community, we pledge to stand against racism and intolerance and strive to elevate the ideas and voices of black, indigenous, and people of color who have been historically excluded because of systemic racism. We thank the support of the software architecture community, they reacted by continuing to advance the field of software architecture through their scientific submissions to ECSA, while staying flexible as the Organizing Committee had to pivot several times from an in-person, to hybrid, to an all-online conference. July 2020

Anton Jansen Ivano Malavolta Henry Muccini Ipek Ozkaya Olaf Zimmermann

Organization

General Chair Henry Muccini

University of L’Aquila, Italy

Steering Committee Muhammad Ali Babar Paris Avgeriou Tomas Bures Rogério de Lemos Laurence Duchien Carlos E. Cuesta David Garlan Paola Inverardi Patricia Lago Antónia Lopes Ivano Malavolta Raffaela Mirandola Henry Muccini Flavio Oquendo (Chair) Ipek Ozkaya Jennifer Pérez Bedir Tekinerdogan Danny Weyns Uwe Zdun

The University of Adelaide, Australia University of Groningen, The Netherlands Charles University, Czech Republic University of Kent, UK CRIStAL, University of Lille, France Rey Juan Carlos University, Spain Carnegie Mellon University, USA University of L’Aquila, Italy Vrije Universiteit Amsterdam, The Netherlands University of Lisbon, Portugal Vrije Universiteit Amsterdam, The Netherlands Politecnico di Milano, Italy University of L’Aquila, Italy IRISA, University of South Brittany, France Carnegie Mellon University, USA Technical University of Madrid, Spain Wageningen University, The Netherlands KU Leuven, Belgium University of Vienna, Austria

Research Track Program Committee Chairs Ivano Malavolta Ipek Ozkaya

Vrije Universiteit Amsterdam, The Netherlands Carnegie Mellon University, USA

Program Committee Jesper Andersson Paris Avgeriou Rami Bahsoon Luciano Baresi Thais Batista Steffen Becker Stefan Biffl

Linnaeus University, Sweden University of Groningen, The Netherlands University of Birmingham, UK Politecnico di Milano, Italy Federal University of Rio Grande do Norte, Brazil University of Stuttgart, Germany TU Wien, Austria

viii

Organization

Barbora Buhnova Tomas Bures Javier Cámara Rafael Capilla Jan Carlson Siobhán Clarke Vittorio Cortellessa Carlos Cuesta Rogerio De Lemos Elisabetta Di Nitto Andres Diaz Pace Khalil Drira Laurence Duchien Neil Ernst George Fairbanks Matthias Galster Ilias Gerostathopoulos Carlo Ghezzi Volker Gruhn Petr Hnetynka Paola Inverardi Pooyan Jamshidi Wouter Joosen Anne Koziolek Heiko Koziolek Patricia Lago Nuno Laranjerio Nicole Levy Grace Lewis Antónia Lopes Kristina Lundquist Sam Malek Tomi Männistö Antonio Martini Tommi Mikkonen Mehdi Mirakhorli Raffaela Mirandola Marina Mongiello Gabriel Moreno Juan Manuel Elisa Yumi Elena Navarro Flavio Oquendo Claus Pahl Liliana Pasquale Cesare Pautasso

Masaryk University, Czech Republic Charles University, Czech Republic University of York, UK Rey Juan Carlos University, Spain Malardalen University, Sweden Trinity College Dublin, Ireland University of L’Aquila, Italy Rey Juan Carlos University, Spain University of Kent, UK Politecnico di Milano, Italy UNICEN University, Argentina LAAS-CNRS, France University of Lille, France University of Victoria, Canada Google, USA University of Canterbury, New Zealand TU Munich, Germany Politecnico di Milano, Italy Universität Duisburg-Essen, Germany Charles University, Czech Republic University of L’Aquila, Italy University of South Carolina, USA KU Leuven, Belgium Karlsruhe Institute of Technology, Germany ABB Corporate Research, Germany Vrije Universiteit Amsterdam, The Netherlands University of Coimbra, Portugal CNAM, France Carnegie Mellon University, USA University of Lisbon, Portugal Malardalen University, Sweden University of California, Irvine, USA University of Helsinki, Finland University of Oslo, Norway University of Helsinki, Finland Rochester Institute of Technology, USA Politecnico di Milano, Italy Politecnico di Bari, Italy Carnegie Mellon University, USA Murillo University of Extremadura, Spain Nakagawa University of São Paulo, Brazil University of Castilla-La Mancha, Spain Université Bretagne Sud, France Free University of Bozen-Bolzano, Italy University College Dublin, LERO, Ireland USI Lugano, Switzerland

Organization

Patrizio Pelliccione Jennifer Perez Claudia Raibulet Maryam Razavian Ralf Reussner Bradley Schmerl Romina Spalazzese Girish Suryanarayana Bedir Tekinerdogan Chouki Tibermacine Rainer Weinreich Danny Weyns Uwe Zdun Liming Zhu Olaf Zimmermann

Chalmers University of Technology, Sweden Universidad Politécnica de Madrid, Spain University of Milano-Bicocca, Italy Eindhoven University of Technology, The Netherlands Karlsruhe Institute of Technology, Germany Carnegie Mellon University, USA Malmö University, Sweden Siemens Corporate Technology, India Wageningen University, The Netherlands University of Montpellier, France Johannes Kepler University Linz, Austria KU Leuven, Belgium University of Vienna, Austria The University of New South Wales, Australia Hochschule für Technik Rapperswill, Switzerland

Additional Reviewers Anastase Adonis Abdulatif Alabdulatif Maria Istela Cagnin Everton Cavalcante Milena Guessi

Axel Legay Samir Ouchani Eduardo Silva Roberto Verdecchia

Industry Track Program Committee Chairs Anton Jansen Olaf Zimmermann

Philips, The Netherlands Hochschule für Technik Rapperswil, Switzerland

Program Committee Mohsen Anvaari Andrei Furda Heiko Koziolek Thomas Kurpick Xabier Larrucea Daniel Lübke Željko Obrenović Eltjo Poort Daniele Spinosi Michael Stal Johannes Wettinger Erik Wittern Eoin Woods

ix

Independent Consultant, Norway Hitachi Rail STS, Australia ABB Corporate Research, Germany Trusted Shops, Germany Tecnalia, Spain iQuest GmbH, Germany Incision, The Netherlands CGI, The Netherlands Micron Technology, Italy Siemens, Germany Bosch, Germany IBM T.J. Watson Research Center, USA Endava, UK

x

Organization

Additional Reviewers Stefan Kapferer Mirko Stocker

Organizing Committee Proceedings Chair Mirco Franzago

University of L’Aquila, Italy

Web Chair Karthik Vaidhyanathan

Gran Sasso Science Institute, Italy

Tool Demos Chairs Paris Avgeriou Barbora Buhnova

University of Groningen, The Netherlands Masaryk University, Czech Republic

Gender Diversity in SA Chairs Javier Camara Catia Trubiani

University of York, UK Gran Sasso Science Institute, Italy

Doctoral Symposium Chairs Patrizia Scandurra Danny Weyns

DIIMM, University of Bergamo, Italy KU Leuven, Belgium

Workshops Chairs Mauro Caporuscio Anne Koziolek

Linnaeus University, Sweden Karlsruhe Institute of Technology, Germany

Journal First Chair Uwe Zdun

University of Vienna, Austria

Publicity Chairs Stéphanie Challita Juergen Musil

Inria, France TU Wien, Austria

Student Volunteer Chairs Roberta Capuano Jamal El Hecham

University of L’Aquila, Italy IRISA, France

Organization

Virtualization Chairs Claudio Di Sipio Luca Traini

University of L’Aquila, Italy University of L’Aquila, Italy

xi

Keynotes

AI Engineering — New Challenges in System and Software Architecting and Managing Lifecycle for AI-based Systems

Ivica Crnkovic Chalmers University, Gothenburg, Sweden [email protected] Abstract. Artificial Intelligence based on Machine Learning, and in particular Deep Learning, is today the fastest growing trend in software development, and literally used in all other research disciplines, with a very high impact on the modern society. However, a wide use of AI in many systems, in particular dependable systems, is still far away of being widely used. On the one hand there is a shortage of expertise, on the other hand the challenges for managing AI-based complex and dependable systems are enormous, though less known, and in general underestimated. Some aspects of these challenges are based on management of resources, including computational, data storage capacity, performance, and real-time constraints. Introduction of AI-based components, i.e. components that includes AI algorithms, require significant changes in system and software architecture, and its successful deployment is based on many architectural decisions and on changes of the development process. This talk discusses some of these challenges, illustrate a case of Cyber-physical systems, and gives some ideas for new research in software engineering inducing software architecture, i.e. for AI engineering.

Short Bio Ivica Crnkovic is a professor of software engineering at Chalmers University, Gothenburg, Sweden. He is the director of ICT Area of Advance at Chalmers University, and the director of Chalmers AI Research Centre (CHAIR). His research interests include, software architecture, software development processes, software engineering for large complex systems, component-based software engineering, and recently Software engineering for AI. Professor Crnkovic is the author of more than 200 refereed publications on software engineering topics, and guest editor of a number of special issues in different journals and magazines, such as IEEE Software, and Elsevier JSS. He was the general chair of 40th International Conference on Software Engineering (ICSE) 2018, held in Gothenburg, 2018. Before Chalmers, Ivica Crnkovic was affiliated with Mälardalen University, Sweden, and before that he was employed at ABB company, Sweden, where he was responsible for software development environments and tools. More information is available on http://www.ivica-crnkovic.net

Fifty Years of Sustained Progress: Form, Forces, and Lessons of Unix Architectural Evolution

Diomidis Spinellis Department of Management Science and Technology, Athens University of Economics and Business, Greece [email protected] Abstract. Unix has evolved over five decades, shaping modern operating systems, key software technologies, and development practices. Studying the evolution of this remarkable system from an architectural perspective can provide insights on how to manage the growth of large, complex, and long-lived software systems. Along main Unix releases leading to the FreeBSD lineage we examine core architectural design decisions, the number of features, and code complexity, based on the analysis of source code, reference documentation, and related publications. We see that the growth in size has been uniform, with some notable outliers, while cyclomatic complexity has been religiously safeguarded. A large number of Unix-defining design decisions were implemented right from the very early beginning, with most of them still playing a major role. Unix continues to evolve from an architectural perspective, but the rate of architectural innovation has slowed down over the system’s lifetime. Architectural technical debt has accrued in the forms of functionality duplication and unused facilities, but in terms of cyclomatic complexity it is systematically being paid back through what appears to be a self-correcting process. Some unsung architectural forces that shaped Unix are the emphasis on conventions over rigid enforcement, the drive for portability, a sophisticated ecosystem of other operating systems and development organizations, and the emergence of a federated architecture, often through the adoption of third-party subsystems. These findings allow us to form an initial theory on the architecture evolution of large, complex operating system software.

Short Bio Diomidis Spinellis is a Professor in the Department of Management Science and Technology at the Athens University of Economics and Business, Greece. His research interests include software engineering, IT security, and cloud systems engineering. He has written two award-winning, widely- translated books: “Code Reading” and “Code Quality: The Open Source Perspective”. His most recent book is “Effective Debugging: 66 Specific Ways to Debug Software and Systems”. Dr. Spinellis has also published more than 300 technical papers in journals and refereed conference proceedings, which have received more than 8000 citations. He served for a decade as a member of the

Fifty Years of Sustained Progress: Form, Forces, and Lessons of Unix

xvii

IEEE Software editorial board, authoring the regular “Tools of the Trade” column, and as the magazine’s Editor-in- Chief over the period 2015–2018. He has contributed code that ships with Apple’s macOS and BSD Unix and is the developer of UMLGraph, CScout, git-issue, and other open-source software packages, libraries, and tools. Dr. Spinellis is a senior member of the ACM and the IEEE.

Mighty Methods: Four Essential Tools for Every Software Architect’s Silver Toolbox

Michael Keeling LendingHome, USA [email protected] Abstract. It is an oversimplification to say that we are living in extraordinary times. When my team was first asked to work from home back in February we were happy to do our part in attempting to stem the tide of an inevitable global pandemic. While we were eager to help, we were also nervous about how suddenly distributing our co-located team would affect our way of working. And yet, after several months we’ve settled into a “new normal” that looks surprisingly similar to our way of working from Before. Much about how we worked changed, in some cases dramatically, but a handful of design methods that were central to our team remained effective even after the shift from a co-located to fully distributed context. In particular, mob programming, example mapping, architecture decision records, and visual thinking are consistently among the most versatile and reliable tools in my silver toolbox. In this talk we’ll briefly explore these four methods and speculate about what makes them effective tools for software architects in such a broad range of contexts and situations. While this is not a talk about remote work per se, we’ll attempt to use the shifting context of work we’ve all experienced to further isolate variables that might help us identify other potential mighty methods waiting for software architects to adopt.

Short Bio Michael Keeling is a software engineer at LendingHome and the author of Design It!: From Programmer to Software Architect. Prior to LendingHome, Keeling worked at IBM on the Watson Discovery Service, Vivisimo, BuzzHoney, and Black Knight Technology. Keeling has also served as an Adjunct Faculty member at Carnegie Mellon University in the Master of Software Engineering Distance Program since 2009. He holds a Master in Software Engineering from Carnegie Mellon University in Pittsburgh, PA and a Bachelor of Science in Computer Science from the College of William and Mary in Williamsburg, VA. Keeling’s current research interests include software architecture design methods, agile software development, and human factors of software engineering. He is a regular speaker in the architecture and agile communities, presenting papers and talks, and facilitating workshops for both national and international audiences. Keeling is a two-time winner of the SEI/IEEE Software “Architecture in Practice” Best Presentation Award for talks given at the 2012 and 2014 SATURN conferences. A full list of his talks and workshops are available on his website: http://www.neverletdown.net/p/speaking-and-writing.html.

Contents

Microservices Assessing Architecture Conformance to Coupling-Related Patterns and Practices in Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evangelos Ntentos, Uwe Zdun, Konstantinos Plakidas, Sebastian Meixner, and Sebastian Geiger

3

Formal Software Architectural Migration Towards Emerging Architectural Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nacha Chondamrongkul, Jing Sun, and Ian Warren

21

Monolith Migration Complexity Tuning Through the Application of Microservices Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . João Franscisco Almeida and António Rito Silva

39

Uncertainty, Self-adaptive, and Open System Decentralized Architecture for Energy-Aware Service Assembly . . . . . . . . . . Mauro Caporuscio, Mirko D’Angelo, Vincenzo Grassi, and Raffaela Mirandola

57

Continuous Experimentation for Automotive Software on the Example of a Heavy Commercial Vehicle in Daily Operation . . . . . . . . . . . . . . . . . . Federico Giaimo and Christian Berger

73

Towards Using Probabilistic Models to Design Software Systems with Inherent Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alex Serban, Erik Poll, and Joost Visser

89

Model-Based Approaches Empowering SysML-Based Software Architecture Description with Formal Verification: From SysADL to CSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fagner Dias, Marcel Oliveira, Thais Batista, Everton Cavalcante, Jair Leite, Flavio Oquendo, and Camila Araújo A Flexible Architecture for Key Performance Indicators Assessment in Smart Cities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Martina De Sanctis, Ludovico Iovino, Maria Teresa Rossi, and Manuel Wimmer

101

118

xx

Contents

Performance and Security Engineering A Multi-objective Performance Optimization Approach for Self-adaptive Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Davide Arcelli

139

Data Stream Operations as First-Class Entities in Component-Based Performance Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dominik Werle, Stephan Seifermann, and Anne Koziolek

148

Architecture-Centric Support for Integrating Security Tools in a Security Orchestration Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chadni Islam, Muhammad Ali Babar, and Surya Nepal

165

VisArch: Visualisation of Performance-based Architectural Refactorings . . . . Catia Trubiani, Aldeida Aleti, Sarah Goodwin, Pooyan Jamshidi, Andre van Hoorn, and Samuel Gratzl

182

Architectural Smells and Source Code Analysis An Initial Study on the Association Between Architectural Smells and Degradation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sebastian Herold Architectural Technical Debt: A Grounded Theory . . . . . . . . . . . . . . . . . . . Roberto Verdecchia, Philippe Kruchten, and Patricia Lago Does BERT Understand Code? – An Exploratory Study on the Detection of Architectural Tactics in Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jan Keim, Angelika Kaplan, Anne Koziolek, and Mehdi Mirakhorli

193 202

220

Education and Training Teaching Students Software Architecture Decision Making. . . . . . . . . . . . . . Rafael Capilla, Olaf Zimmermann, Carlos Carrillo, and Hernán Astudillo The PDEng Program on Software Technology: Experience Report on a Doctorate Level Architecture Training Program . . . . . . . . . . . . . . . . . . Ad T. M. Aerts and Yanja Dajsuren

231

247

Experiences and Learnings from Industrial Case Studies Architectural Concerns for Digital Twin of the Organization. . . . . . . . . . . . . Mauro Caporuscio, Farid Edrisi, Margrethe Hallberg, Anton Johannesson, Claudia Kopf, and Diego Perez-Palacin

265

Contents

xxi

Quick Evaluation of a Software Architecture Using the Decision-Centric Architecture Review Method: An Experience Report . . . . . . . . . . . . . . . . . . Pablo Cruz, Luis Salinas, and Hernán Astudillo

281

The Quest for Introducing Technical Debt Management in a Large-Scale Industrial Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Somayeh Malakuti and Sergey Ostroumov

296

Architecting Contemporary Distributed Systems Determining Microservice Boundaries: A Case Study Using Static and Dynamic Software Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tiago Matias, Filipe F. Correia, Jonas Fritzsch, Justus Bogner, Hugo S. Ferreira, and André Restivo

315

IAS: An IoT Architectural Self-adaptation Framework . . . . . . . . . . . . . . . . . Mahyar T. Moghaddam, Eric Rutten, Philippe Lalanda, and Guillaume Giraud

333

A Comparison of MQTT Brokers for Distributed IoT Edge Computing . . . . . Heiko Koziolek, Sten Grüner, and Julius Rückert

352

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

369

Microservices

Assessing Architecture Conformance to Coupling-Related Patterns and Practices in Microservices Evangelos Ntentos1(B) , Uwe Zdun1 , Konstantinos Plakidas1 , Sebastian Meixner2 , and Sebastian Geiger2 1

Faculty of Computer Science, Research Group Software Architecture, University of Vienna, Vienna, Austria {Evangelos.Ntentos,Uwe.Zdun,Konstantinos.Plakidas}@univie.ac.at 2 Siemens Corporate Technology, Vienna, Austria {Sebastian.Meixner,Sebastian.Geiger}@siemens.com

Abstract. Microservices are the go-to architectural style for building applications that are polyglot, support high scalability, independent development and deployment, and are rapidly adaptable to changes. Among the core tenets for a successful microservice architecture is high independence of the individual microservices, i.e. loose coupling. A number of patterns and best practices are well-established in the literature, but most actual microservice-based systems do not, as a whole or in part, conform to them. Assessing this conformance manually is not realistically possible for large-scale systems. This study aims to provide the foundations for an automated approach for assessing conformance to coupling-related patterns and practices specific for microservice architectures. We propose a model-based assessment based on generic, technology-independent metrics, connected to typical design decisions encountered in microservice architectures. We demonstrate and assess the validity and appropriateness of these metrics by performing an assessment of the conformance of real-world systems to patterns through statistical methods.

1

Introduction

Microservice architectures [14,15,22] describe an application as a collection of autonomous and loosely coupled services, typically modeled around a domain. Key microservice tenets are development in independent teams, cloud-native technologies and architectures, polyglot technology stacks including polyglot persistence, lightweight containers, loosely coupled service dependencies, high releasability, and continuous delivery [22]. Many architectural patterns that reflect recommended “best practices” in a microservices context have already been published in the literature [18,19,23]. The fact that microservice-based systems are complex and polyglot means that an automatic or semi-automatic assessment of their conformance to these patterns is difficult: real-world systems feature combinations of these patterns, and different degrees of violations of the c Springer Nature Switzerland AG 2020  A. Jansen et al. (Eds.): ECSA 2020, LNCS 12292, pp. 3–20, 2020. https://doi.org/10.1007/978-3-030-58923-3_1

4

E. Ntentos et al.

same; and different technologies in different parts of the system implement the patterns in different ways, making the automatic parsing of code and identification of the patterns a haphazard process. This work focuses on describing a method for assessing architecture conformance to coupling-related patterns and practices in microservice architectures. Coupling between microservices is caused by existence of dependencies, e.g. whenever one service calls another service to fulfill a request or share data. Loose coupling is an established topic in service-oriented architectures [22] but the application to the specific context of microservice architectures has not, to our knowledge, been examined so far. Strong coupling is conflicting with some of the key microservice tenets mentioned above. In particular, releasability, which is a highly desirable characteristic in modern systems due to the emergence of DevOps practices, relies on the rapid and independent release of individual microservices, and is compromised by strong dependencies between them. For the same reason, development in independent teams becomes more difficult, and independent deployment of individual microservices in lightweight containers is also impeded. This work covers three broad coupling aspects: Coupling through Databases, resulting from reliance on commonly accessed data via shared databases; Coupling through Synchronous Invocations, resulting from synchronous communication between individual services; and Coupling through Shared Services, which arises through the dependence on common shared services (for details see Sect. 3). In reality, of course, no microservice system can support all microservice tenets well at the same time. Rather the architectural decisions for or against the use of specific patterns and practices must reflect a trade-off between ensuring the desired tenets and other important quality attributes [12,22]. From these considerations, this paper aims to study the following research questions: – RQ1 How can we automatically assess conformance to loose coupling-related patterns and practices in the context of microservice architecture decision options? – RQ2 How well do measures for assessing coupling-related decision options and their associated tenets perform? – RQ3 What is a set of minimal elements needed in a microservice architecture model to compute such measures? In pursuing of these questions, we surveyed the relevant literature (Sect. 2) and gathered knowledge sources about established architecture practices and patterns, their relations and tenets in form of a qualitative study on microservice architectures. This enabled us to create a meta-model for the description of microservice architectures, which was verified and refined through iterative application in modelling a number of real-world systems, as outlined in Sect. 4. We manually assessed all models and model variants on whether each decision option is supported, thereby deriving an objective ground truth (Sect. 5). As the basis for an automatic assessment, we defined a number of generic, technology-independent metrics to measure architecture conformance to the decision options, i.e. at least one metric per major decision option (Sect. 6).

Assessing Architecture Conformance

5

These metrics (and combinations thereof) were applied on the models and model variants to derive a numeric assessment, and then compared to the ground truth assessment via an ordinal regression analysis (Sect. 7). Section 8 discusses the results of our approach, as well as its limitations and potential threats to validity. Finally, in Sect. 9 we draw our conclusions and discuss options for future work.

2

Related Work

Many studies focus on best practices for microservice architectures. Richardson [18] has published a collection of microservice patterns related to major design and architectural practices. Patterns related to microservice APIs have been introduced by Zimmermann et al. [23], while Skowronski [19] collected best practices for event-driven microservice architectures. Microservice fundamentals and best practices are also discussed by Fowler and Lewis [14], and are summarized in a mapping study by Pahl and Jamshidi [16]. Taibi and Lenarduzzi [20] study microservice “bad smells”, i.e. practices that should be avoided (which would correspond to violations in our work). Many software metrics-related studies for evaluating the system architecture and individual architectural components exist, but most of them are not specific to the microservices domain. Allen et al. [1,2] study component metrics for measuring a number of quality attributes, e.g. size, coupling, cohesion, dependencies of components, and the complexity of the architecture. Additional studies for assessing quality attributes related to coupling and cohesion have been proposed and validated in the literature [3,4,6,11]. Furthermore, a small number of studies [5,17,21] propose metrics specifically for assessing microservice-based software architectures. Although these works study various aspects of architecture, design metrics, and architecture-relevant tenets such as coupling and independent deployment, their approach is usually generic. None of the works covers all the related software aspects for measuring coupling in a microservice context: the use of databases, system asynchronicity, and shared components. This is the overarching perspective of our work, and the chief contribution of this paper.

3

Decisions

In this section, we briefly introduce the three coupling-related decisions along with their decision options (i.e. the relevant patterns and practices) which we study in this paper. We also discuss the impact on relevant microservice tenets, which we later on use as an argumentation for our manual ground truth assessment in Sect. 5. Inter-Service Coupling Through Databases. One important decision in microservice-based systems is data persistence, which needs to take into account qualities such as reliability and scalability, but also adhere to microservicespecific best practices, which recommend that each microservice should be

6

E. Ntentos et al.

loosely coupled and thus able to be developed, deployed, and scaled independently [14]. At one extreme of the scale, one option is No Persistent Data Storage, which is applicable only for services whose functions are performed on transient data. Otherwise, the most recommended option is the Database per Service pattern [18]: each service has its own database and manages its own data independently. Another option, which negatively affects loose coupling, is to use a Shared Database [18]: a service writes its data in a common database and other services can read these data when required. There are two different ways to implement this pattern: in Data Shared via Shared Database multiple services share the same table, resulting in a strongly coupled system, whereas in Databased Shared but no Data Sharing each service writes to and reads from its own tables, which has a lesser impact on coupling. Inter-Service Coupling Through Synchronous Invocations. Service integration is another core decision when building a microservice-based system. A theoretically optimal system of independent microservices would feature no communication between them. Of course, services need to communicate in reality, and so the question of integrating them so as to not result in tight inter-service coupling becomes paramount. The recommended practice is that communication between the microservices should be, as much as possible, asynchronous. This can be achieved through several patterns which are widely implemented in typical technology stacks: the Publish/Subscribe [13] pattern, in which services can subscribe to a channel to which other services can publish; the use of a Messaging [13] middleware, which decouples communication by using a queue to store messages sent by the producer until they are received by the consumer; the Data Polling [18] pattern, in which services periodically poll other services for data changes; and the Event Sourcing [18] pattern, that ensures that all changes to application state are stored as a sequence of events; Asynchronous Direct Invocation technique, in which services communicate asynchronously via direct invocations. Applying these patterns ensures loose coupling (to different degrees), and increases the system reliability. Inter-Service Coupling Through Shared Services. Many of the microservice patterns focus on system structure, i.e. avoiding services sharing other services altogether, or at least not in a strongly coupled way. An optimal system in terms of architecture quality should not have any shared service. In reality, this is often not feasible, and in larger systems service sharing leads to chains of transitive dependencies between services. This is problematic when a service is unaware of its transitive dependencies, and of course for the shared service itself, where the needs of its dependents must always be taken into account during its evolution. We define three cases: a Directly Shared Service is a microservice which is directly linked to and required by more than one other service; a Transitively Shared Service is a microservice which is linked to other services via at least one intermediary service; and a Cyclic Dependency [10] which is formed when there is a direct or transitive path that leads back to its origin, i.e. that allows a service to be ultimately dependent on itself after a number of intermediary services. Cyclic dependencies often emerge inadvertently through increasing complexity

Assessing Architecture Conformance

7

over the system’s lifecycle, and require extensive refactoring to resolve. All three cases are inimical to the principle of loose coupling as well as to system qualities such as performance, modifiability, reusability, and scalability.

4

Research and Modeling Methods

In this section, we summarize the research and modeling methods applied in our study. The code and models used in and produced as part of this study have been made available online for reproducibility1 . 4.1

Research Method

Figure 1 shows the research steps from initial data collection to final data analysis. For the data collection phase we conducted a multi-vocal literature study using web resources, public repositories, and scientific papers as sources [9]. We then analyzed the data collected using qualitative methods based on Grounded Theory [7] coding methods, such as open and axial coding, and extracted the three core architectural decisions described in the previous section along with their corresponding decision drivers and impacts. As data for our further research we used generated models taken from the Model Generation process, described below. We defined a rating scheme for systematic assessment based on support or violation of core practices and tenets. From these we derived a ground truth for our study (the ground truth and its calculation rules are described in Sect. 5) as well as a set of metrics for automatically calculating conformance to each individual pattern or practice per decision. We then used the ground truth data to assess how well the hypothesized metrics can possibly predict the ground truth data by performing an ordinal regression analysis. Ordinal regression is a widely used method for modeling an ordinal response’s dependence on a set of independent predictors, which is applicable in a variety of domains. For the ordinal regression analysis we used the lrm function from the rms package in R [8]. 4.2

Model Generation

We began by performing an iterative study of a variety of microservice-related knowledge sources, and we gradually refined a meta-model which contains all the required elements to help us reconstruct existing microservice-based systems. In order to investigate the ontology, and to evaluate the meta-model’s efficiency, we gathered a number of microservice-based systems, summarized in Table 1. Each is either a system published by practitioners (on GitHub and/or practitioner blogs) or a system variant adapted from a published example according to discussions in the relevant literature in order to explore the possible decision space. Apart from the specific variations described in Table 1 all other system aspects remained the same as in the base models. 1

https://bit.ly/2WmFP3N.

8

E. Ntentos et al. Data Collection Phase

Data Analysis

Architectural Design Decisions

Formulation of Core Decisions

Repositories Extract Ontology (Data Types) from best practices and tenets

Definition of Decision Options: Patterns and practices

Research Papers

Data Analysis: Qualitative study based on Grounded Theory method

Web Resources

Determine Decision Impacts for each option

Metrics Definition

Statistical Evaluation

Metrics Evaluation: Regression analysis on ability of the metrics to predict the ground truth assessment

Extraction of Decision Drivers: Quality attributes/Tenets

Objective Assessment

Define Metrics for quantifying extent of support/violation of each pattern/practice and tenet

Establish a Rating Scheme for System Assessment: Ordinal scale based on support or violation of patterns/practices and tenets

Automatic Calculation of generated metrics based on the system component models

Ground Truth Definition: Manual assessment of system model according to rating scheme

Model Generation

Static Code Analysis

Codeable Models Generator

System Component Model

Model Visualisation

Fig. 1. Overview diagram of the research method followed in this study

The systems were taken from 9 independent sources in total. They were developed by practitioners with microservice experience, and they are representative of the best practices summarized in Sect. 3. We performed a fully manual static code analysis for those models where the source code was available (7 of our 9 sources; two were modeled from documentation published by the practitioners). To create our models, we used our existing modeling tool CodeableModels2 , a Python implementation for the precise specification of meta-models, models, and model instances in code. Based on CodeableModels, we specified meta-models for components, connectors and relationships. We then manually created model instances for each of the systems in Table 1. In addition, we realized automated constraint checkers and PlantUML code generators to generate graphical visualizations of all meta-models and models. The result is a set of precisely modeled component models of the examined software systems (modeled using the techniques described below). This resulted in a total of 27 models summarized in Table 1. We assume that our evaluation systems are, or reflect, real-world practical examples of microservice architectures. As many of them are open source systems with the purpose of demonstrating practices or technologies, they are at most of medium size and modest complexity, though. 2

https://github.com/uzdun/CodeableModels.

Assessing Architecture Conformance

4.3

9

Methods for Modeling Microservice Component Architectures

From an abstract point of view, a microservice-based system is composed of components and connectors, with a set of component types for each component and a set of connector types for each connector. For modeling microservice architectures we followed the method reported in our previous work [21].

5

Ground Truth Calculations

In this section, we present and describe the calculation of the ground truth assessment for each of the decisions from Sect. 3. The results of those assessments are reported in Table 2. The assessment begins with a manual evaluation by the authors on whether each of the relevant patterns (decision options) is either Supported, Partially Supported, or Not Supported (S, P, N in Table 2). Based on this and informed by the description of the impacts of the various decision options in Sect. 3, we combined the outcome of all decision options to derive an ordinal assessment on how well the decision as a whole is supported in each model, using the ordinal scale: [ ++: very well supported, +: well supported, o: neutral, -: badly supported, --: very badly supported]. This was done according to best practices documented in literature. For instance, following the ordinal scale the assessment for the model BM1 is +: well supported, since a) option Database per Service is not supported, b) some services have a shared database, but c) they do not share data via the shared database. For the Inter-Service Coupling through Databases decision, we derive the following scoring scheme for our ground truth assessment: • ++: All services (which require data persistence) have individual databases Database per Service. • +: Some services have Shared Databases and no Data Shared via the Shared Databases. • o: All services have Shared Databases and no Data Shared via the Shared Databases. • -: Some services have Shared Databases and Data Shared via the Shared Databases. • --: All services have Shared Databases and Data Shared via the Shared Databases. From the Inter-Service Coupling through Synchronous Invocations decision, we derive the following scoring scheme for our ground truth assessment: • ++: All services communicate asynchronously via Message Brokers or Publish/Subscribe or Stream Processing • +: All services communicate asynchronously via API Gateway or HTTP Polling or Direct Asynchronous calls, or (some) via Message Brokers or Publish/Subscribe or Stream Processing. • o: None or some services communicate asynchronously and all other services communicate asynchronously via Data Sharing (e.g. Shared DB).

10

E. Ntentos et al. Table 1. Overview of modelled systems (size, details, and sources) Model ID

Model Size

Description / Source

BM1

10 components 14 connectors

Banking-related application based on CQRS and event sourcing (from https:// github.com/cer/event-sourcing-examples).

BM2

8 components 9 connectors

Variant of BM1 which uses direct RESTful completely synchronous service invocations instead of event-based communication.

BM3

8 components 9 connectors

Variant of BM1 which uses direct RESTful completely asynchronous service invocations instead of event-based communication.

CO1

8 components 9 connectors

The common component model E-shop application implemented as microservices directly accessed by a Web frontend (from https://github.com/cocomecommunity-case-study/cocome-cloud-jee-microservices-rest).

CO2

11 components 17 connectors

Variant of CO1 using a SAGA orchestrator on the order service with a message broker. Added support for Open Tracing. Added an API gateway.

CO3

9 components 13 connectors

Variant of CO1 where the reports service does not use inter-service communication, but a shared database for accessing product and store data. Added support for Open Tracing.

CI1

11 components 12 connectors

Cinema booking application using RESTful HTTP invocations, databases per service, and an API gateway (from https://codeburst.io/build-a-nodejscinema-api-gateway-and-deploying-it-to-docker-\part-4703c2b0dd269).

CI2

11 components 12 connectors 10 components 11 connectors 11 components 12 connectors

Variant of CI1 routing all interservice communication via the API gateway.

EC1

10 components 14 connectors

E-commerce application with a Web UI directly accessing microservices and an API gateway for service-based API (from https://microservices.io/patterns/ microservices.html).

EC2

11 components 14 connectors 8 components 11 connectors 20 components 36 connectors

Variant of EC1 using event-based communication and event sourcing internally.

ES2

14 components 35 connectors

Variant of ES1 using RESTful communication via the API gateway instead of eventbased communication and one shared SQL DB for all 6 of the services using DBs. No service interaction via the shared database occurs.

ES3

16 components 35 connectors

Variant of ES1 using RESTful communication via the API gateway instead of eventbased communication and one shared database for all 4 of the services using SQL DB in ES1. However, no service interaction via the shared database occurs.

FM1

15 components 24 connectors

Simple food ordering application based on entity services directly linked to a Web UI (from https://github.com/jferrater/Tap-And-EatMicroServices).

FM2

14 components 21 connectors

Variant of FM1 which uses the store service as an API composition and asynchronous interservice communication. Added Jaeger-based tracing per service.

FM3

13 components 15 connectors

Variant of FM1 which demonstrates a cyclic dependency case, uses the store service as an API composition and asynchronous inter-service communication

HM1

13 components 25 connectors

Hipster shop application using GRPC interservice connection and OpenCensus monitoring & tracing for all but one services as well as on the gateway. (from https: //github.com/GoogleCloudPlatform/microservices-demo).

HM2

14 components 26 connectors

Variant of HM1 that uses publish/subscribe interaction with event sourcing, except for one service, and realizes the tracing on all services.

RM1

11 components 18 connectors

Restaurant order management application based on SAGA messaging and domain event interactions. Rudimentary tracing support (from https://github.com/ microservices-patterns/ftgo-application).

RM2

14 components 14 connectors

Variant of RM1 which contains transitively shared services, API Gateway for client services communication, database per service and direct communication between service.

RM3

14 components 15 connectors

Variant of RM1 which demonstrates a cyclic dependency case, API Gateway for client services communication, database per service and direct communication between service.

RS

18 components 29 connectors

Robot shop application with various kinds of service interconnections, data stores, and Instana tracing on most services (from https://github.com/instana/robotshop).

TH1

14 components 16 connectors

Taxi hailing application with multiple frontends and databases per services from (https://www.nginx.com/blog/introduction-to-microservices/).

TH2

15 components 18 connectors

Variant of TH1 that uses publish/subscribe interaction with event sourcing for all but one service interactions.

CI3 CI4

EC3 ES1

Variant of CI1 using direct client to service invocations instead of the API gateway. Variant of CI1 with a subsystem exposing services directly to the client and another subsystem routing all traffic via the API gateway.

Variant of EC1 with a shared database used to handle all but one service interactions. E-shop application using pub/sub communication for event-based interaction, a middleware-triggered identity service, databases per service (4 SQL DBs, 1 Mongo DB, and 1 Redis DB), and backends for frontends for two Web app types and one mobile app type (from https://github.com/dotnet-architecture/ eShopOnContainers).

P

N

+

Data Shared via Shared DB

Assessments

N

N

S

N

N

S

N

N

S P

P

P

++ ++ ++ ++ -

N

N

S

N

N

N

++ --

Asynch Inter-communication via API GW

Shared Database Interconnections

Messaging Interconnections

Assessments

-

N

N

S

N

N

--

N

N

N

N

N

N

N

N

N

N

N

N

++ ++ ++ ++ ++ ++ o

P

N

N

Assessments

N

Cyclic Dependencies

N

N

N

N

N

N

N

--

N

N

N

N

N

Direct Service Sharing N

N

N

N

S N

N

S N

N

S N

N

S N

N

S S

S

N

N

N

P

--

N

N

N

N

N

++ o

N

N

N

--

N

N

N

N

N

N

N

N

--

N

N

N

N

N

N

S

N

N

N

N

N

N

N

N

N

++ o

N

N

N

S

N

N

S

N

N

N

P

+

N

N

N

P

N

o

N

N

P

--

N

N

N

N

N

++ o

N

N

S

++ ++ ++ ++ o

N

N

N

--

N

N

N

N

N

++ ++ ++ ++ ++ ++ --

N

N

S

Transitively Shared Services

N

N

P

N

N

N

++ -

S

N

N

N

N

Inter-service coupling through shared services

N

N

N

N

S

PubSub/Event Sourcing Interconnections

N

N

Asynchronous Direct Interconnections

Inter-service coupling through synchronous invocations

N

Database per Service

Shared Database

Database-based inter-service coupling

o

N

N

P

--

N

N

N

N

N

+

N

P

P N

N

S N

N

S N

N

S

S N

N

N N

S

o

N

N

P

--

N

N

N

N

N

o

N

N

P

+

N

N

N

N

S

--

S

P

P

+

N

N

N

N

S

o

N

N

P

-

N

N

N

N

P

P

N

N

P

N

N

N

N

S

S N

N

N N

S

N

S

N

--

N

N

N

N

N

--

S

N

N

--

N

N

N

N

N

o

N

N

P

o

P

N

N

N

P

++ ++ o

N

N

++ ++ o

N

N

N

++ +

N

N

N

S

P

++ ++ ++ ++ ++ o

N

N

S

S N

N

o

N

N

P

--

N

N

N

N

N

++

N

N

N

+

N

N

N

P

N

++ ++

N

N

S

BM1 BM2 BM3 CO1 CO2 CO3 CI1 CI2 CI3 CI4 EC1 EC2 EC3 ES1 ES2 ES3 FM1 FM2 FM3 HM1 HM2 RM1 RM2 RM3 RS TH1 TH2

Table 2. Ground truth assessment results

Assessing Architecture Conformance 11

12

E. Ntentos et al.

• -: None or some services communicate asynchronously, none or some communicate asynchronously via Data Sharing, some services communicate synchronously. • --: All services communicate synchronously. Finally, from the Inter-Service Coupling through Shared Services decision, we derive the following scoring scheme for our ground truth assessment: • ++: None of the services is a Directly Shared Service or Transitively Shared Service and no Cyclic Dependencies exist. • +: Some of the services are Transitively Shared Services, but none are Directly Shared Services and no Cyclic Dependencies exist. • o: Some or none of the services are Transitively Shared Services and some are Directly Shared Services, but no Cyclic Dependencies exist. • -: Some of the services are Transitively Shared Services and all other services are Directly Shared Services, but no Cyclic Dependencies exist. • --: There are Cyclic Dependencies or all the services are Transitively Shared Components and all the services are Directly Shared Components.

6

Metrics

In this section, we describe the metrics we have hypothesized for each of the decisions described in Sect. 3. All metrics, unless otherwise noted, are a continuous value with range from 0 to 1, with 1 representing the optimal case where a set of patterns is fully supported, and 0 the worst-case scenario where it is completely absent. 6.1

Metrics for Inter-Service Coupling Through Databases Decision

Database Type Utilization (DTU) Metric. This metric returns the number of the connectors from Services to Individual Databases in relation to the total number of Service-to-Database connectors. This way, we can measure how many services are using individual databases. DT U =

Database per Service Links T otal Service-to-Database Links

Shared Database Interactions (SDBI) Metric. Although a Shared Database is considered as an anti-pattern in microservices, there are many systems that make use of it either partially or completely. To measure its presence in a system, we count the number of interconnections via a Shared Database compared to the total number of service interconnections. SDBI =

Service Interconnections with Shared Database T otal Service Interconnections

Assessing Architecture Conformance

6.2

13

Metrics for Inter-Service Coupling Through Synchronous Invocations Decision

Service Interaction via Intermediary Component (SIC) Metric. We defined this metric to measure the proportion of service interconnections via asynchronous relay architectures such as Message Brokers, Publish/Subscribe, or Stream Processing. These represent the best current practices, and are not exhaustive; should any new architectures emerge, these should be added to this list. SIC =

Service Interconnections via [M essage Brokers | P ub/Sub | Stream] T otal Service Interconnections

Asynchronous Communication Utilization (ACU) Metric. This metric measures the proportion of the sum of asynchronous service interconnections (via API Gateway/HTTP Polling/Direct calls/Shared Database) to the total number of service interconnections. ACU =

6.3

Asynchronous Service Interconnections via [AP I | P olling | Direct Calls | Shared DB] T otal Service Interconnections

Metrics for Inter-Service Coupling Through Shared Services Decision

Direct Service Sharing (DSS) Metric. For measuring DSS we count all the directly shared services and set this number in relation to the total number of system services. To this add all the shared services connectors in relation to the total number of services interconnections. This gives us the proportion of the directly shared elements in the system. Shared Services Shared Services Connectors + T otal Services T otal Service Interconnections DSS = 2

Transitively Shared Services (TSS) Metric. For measuring TSS we count all the transitively shared services and set this number in relation to the total number of system services. To this we add all the transitively shared service connectors in relation to the total number of service interconnections. This gives us the proportion of the transitively shared elements in the system. T ransitively Shared Services T ransitively Shared Services Connectors + T otal Services T otal Service Interconnections T SS = 2

14

E. Ntentos et al.

Cyclic Dependencies Detection (CDD) Metric. Let SG = (S, C) be the service graph, S the set of service nodes, and C the set of connector edges in a microservice model. Based on the generic definition of closed paths, we define a closed service path in SG as a sequence of services s1 , s2 , . . . , sn (each service ∈ S) such that (sn , sn + 1) ∈ C is a directed connector between services for i = 1, 2, . . . , n and s1 = sn . A service cycle is a closed service path in which no service node is repeated except the first and last, and which contains at least two distinct service nodes. Let ServiceCycles() return the set of all service cycles in a service graph. CDD returns 1 (True) if there is at least one cyclic dependency in the model:  CDD =

6.4

1: 0:

if |ServiceCycles(SG)| = 0 otherwise

Metrics Calculation Results

We note that for the Inter-Service Coupling through Shared Services decision as well as SDBI metric, our metrics scale is reversed in comparison to the other two decisions, because here we detect the presence of an anti-pattern: the optimal result of our metrics is 0, and 1 is the worst-case result. The metrics results for each model per decision metric are presented in Table 3.

7

Ordinal Regression Analysis Results

The dependent outcome variables are the ground truth assessments for each decision, as described in Sect. 5 and summarized in Table 2. The metrics defined in Sect. 6 and summarized in Table 3 are used as the independent predictor variables. The ground truth assessments are ordinal variables, while all the independent variables are measured on a scale from 0.0 to 1.0. The objective of the analysis is to predict the likelihood of the dependent outcome variable for each of the decisions by using the relevant metrics for each decision. Each resulting regression model consists of a baseline intercept and the independent variables multiplied by coefficients. There are different intercepts for each of the value transitions of the dependent variable (≥Badly Supported, ≥Neutral, ≥Well Supported, ≥Very Well Supported ), while the coefficients reflect the impact of each independent variable on the outcome. For example, a positive coefficient, such as +5, indicates a corresponding five-fold increase in the dependent variable for each unit of increase in the independent variable; conversely, a coefficient of −30 would indicate a thirty-fold decrease. The statistical significance of each regression model is assessed by the p-value; the smaller the p-value, the stronger the model. A p-value smaller than 0.05 is

Assessing Architecture Conformance

15

Table 3. Metrics calculation results Metrics BM1 BM2 BM3 CO1 CO2 CO3 CI1

CI2

CI3

CI4

EC1 EC2 EC3

Database-based inter-service coupling DTU

0.33 1.00 1.00 1.00 1.00 0.60 1.00 1.00 1.00 1.00 1.00 1.00 0.00

SDBI

0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00

Inter-service coupling through synchronous invocations SIC

1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 0.00

ACU

0.00 0.00 1.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00

Inter-service coupling through shared services DSS

0.00 0.00 0.00 0.00 0.00 0.00 0.20 0.00 0.38 0.00 0.00 0.00 0.00

TSS

0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

CDD

0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

Metrics ES1 ES2 ES3 FM1 FM2 FM3 HM1 HM2 RM1 RM2 RM3 RS

TH1 TH2

Database-based inter-service coupling DTU

1.00 0.00 0.33 1.00 1.00 1.00 1.00 1.00 0.00 1.00 1.00 0.66 1.00 1.00

SDBI

0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

Inter-service coupling through synchronous invocations SIC

0.60 0.00 0.00 0.00 0.00 0.00 0.00 0.80 1.00 0.00 0.00 0.11 0.00 0.60

ACU

0.00 0.00 0.00 0.00 1.00 0.08 0.50 0.20 0.00 0.00 0.00 0.11 0.00 0.00

Inter-service coupling through shared services DSS

0.27 0.34 0.34 0.62 0.47 0.55 0.52 0.00 0.00 0.00 0.00 0.36 0.33 0.00

TSS

0.00 0.00 0.00 0.00 0.00 0.18 0.00 0.00 0.00 0.18 0.16 0.00 0.00 0.00

CDD

0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00

generally considered statistically significant. In Table 4, we report the p-values for the resulting models, which in all cases are very low, indicating that the sets of metrics we have defined are able to predict the ground truth assessment for each decision with a high level of accuracy. Table 4. Regression analysis results Intercepts/coefficients

Value

Model p-value

Database-based inter-service coupling Intercept (≥Badly Supported)

2.6572

Intercept (≥Neutral)

0.8789

Intercept (≥Well Supported)

−1.3820

1.706019e−06

Intercept (≥Very Well Supported) −3.1260 Metric Coefficient (DTU)

6.4406

Metric Coefficient (SDBI)

−3.7048 (continued)

16

E. Ntentos et al. Table 4. (continued) Inter-service coupling through synchronous invocations Intercept (≥Badly Supported)

−2.6973

Intercept (≥Neutral)

−4.4087

Intercept (≥Well Supported)

−5.8513

6.705525e−11

Intercept (≥Very Well Supported) −15.3677 Metric Coefficient (SIC)

17.3520

Metric Coefficient (ACU)

6.5520

Inter-service coupling through shared services Intercept (≥Neutral)

59.4089

1.625730e−10

Intercept (≥Very Well Supported) 9.7177

8

Metric Coefficient (DSS)

−82.4474

Metric Coefficient (TSS)

−122.2583

Metric Coefficient (CDD)

−57.4650

Discussion

In this section, we first discuss what we have learned in our study that helps to answer the research questions and then discuss potential threats to validity. 8.1

Discussion of Research Questions

To answer RQ1 and RQ2, we proposed a set of generic, technology-independent metrics for each coupling-related decision, and to each decision option corresponds at least one metric. We objectively assessed for each model how well patterns and/or practices are supported for establishing the ground truth, and extrapolated this to how well the broader decision is supported. We formulated metrics to numerically assess a pattern’s implementation in each model, and performed an ordinal regression analysis using these metrics as independent variables to predict the ground truth assessment. Our results show that every set of decision-related metrics can predict our objectively evaluated assessment with high accuracy. This suggests that automatic metrics-based assessment of a system’s conformance to the tenets embodied in each design decision is possible with a high degree of confidence. Here, we make the assumption that the source code of a system can be mapped to the models used in our work. To enable this, we used rather simplistic modeling means, which can rather easily be mapped from a specific source code to the system models. However, it should be noted that full automation of this mapping is an additional effort that needs to be considered and is the subject of ongoing work on our part.

Assessing Architecture Conformance

17

Regarding RQ3, we consider that existing modeling practices can be easily mapped to our microservice meta-model and there is no need for major extensions. More specifically, for completing the modeling of our evaluation system set, we needed to introduce 25 component types and 38 connector types, ranging from general notions such as the Service component type, to very technologyspecific classes such as the RESTful HTTP connector, which is a subclass of Service Connector. Our study shows that for each pattern and practice embodied in each decision, and the proposed metrics, only a small subset of the meta-model is required. The decisions Inter-Service Coupling through Databases and Inter-Service Coupling through Shared Services require to model at least the Service and the Database component types and the technology-related connector types (e.g. Database Connector, RESTful HTTP and Asynchronous Connector) and the read/write process which explicitly modeled in the Database Connector type. The Inter-Service Coupling through Synchronous Invocations decision requires a number of additional components (e.g. Event Sourcing, Stream Processing, Messaging, PubSub) and the respective connectors (e.g. Publisher, Subscriber, Message Consumer, Messages Producer, RESTful HTTP and Asynchronous Connector) to be modeled. 8.2

Threats to Validity

We deliberately relied on third-party systems as the basis for our study to increase internal validity, thus avoiding bias in system composition and structure. It is possible that our search procedures introduced some kind of unconscious exclusion of certain sources; we mitigated this by assembling an author team with many years of experience in the field (including substantial industry experiences), and performing very general and broad searches. Given that our search was not exhaustive, and that most of the systems we found were made for demonstration purposes, i.e. relatively modestly sized, this means that some potential architecture elements were not included in our meta-model. In addition, this raises a possible threat to external validity of generalization to other, and more complex, systems. We nevertheless feel confident that the systems documented are a representative cross-cut of current practices in the field, as the points of variance between them were limited and well attested in the literature. Another potential threat is the fact that the variant systems were derived by the author team. However, this was done according to best practices documented in literature. We carefully made sure only to change specific aspects in a variant and keep all other aspects stable. That is, while the variants do not represent actual systems, they are reasonable evolutions of the original designs. The modeling process is also considered as source of internal validity threat. The models of the systems were repeatedly and independently cross-checked by the author team that has considerable experience in similar methods, but the possibility of some interpretative bias remains: other researchers might have coded or modeled differently, leading to different models. As a mitigation, we also offer the whole models and the code as open access artifacts for review. Since

18

E. Ntentos et al.

we aimed only to find one model that is able to specify all observed phenomena, and this was achieved, we consider this threat not to be a major issue for our study. The ground truth assessment might also be subject to different interpretations by different practitioners. For this purpose, we deliberately chose only a three-step ordinal scale, and given that the ground truth evaluation for each decision is fairly straightforward and based on best practices, we do not consider our interpretation controversial. Likewise, the individual metrics used to evaluate the presence of each pattern were deliberately kept as simple as possible, so as to avoid false positives and enable a technology-independent assessment. As stated previously, generalization to more complex systems might not be possible without modification. But we consider that the basic approach taken when defining the metrics is validated by the success of the regression models.

9

Conclusions and Future Work

Our approach considered that it is achievable to develop a method for automatically assessing coupling related tenets in microservice decisions based on a microservice system’s component model. We have shown that this is possible for microservice decision models that contain patterns and practices as decision options. In this work, we first modeled the key aspects of the decision options using a minimal set of component model elements. These could be possibly automatically extracted from the source code. Then we derived at least one metric per decision option and used a small reference model set as a ground truth. We then used ordinal regression analysis for deriving a predictor model for the ordinal variable. The statistical analysis shows that each decision related metrics are quite close to the manual, pattern-based assessment. There are many studies related on metrics for component model and other architectures so far, but specifically for microservice architectures and their coupling related tenets have not been studied. Based on our discussion in Sect. 2, assessing microservice architectures using general metrics it is not very helpful. Our approach is one of the first that studies a metrics-based assessment of coupling-related tenets in the microservices domain. We aim to a continuous assessment, i.e. we envision an impact on continuous delivery practices, in which the metrics are assessed with each delivery pipeline run, indicating improvement, stability, or deterioration in microservice architecture conformance. With small changes, our approach could also be applied, for instance, during early architecture assessment. As future work, we plan to study more decisions, tenets, and related metrics. We also plan to create a larger data set, thus better supporting tasks such as early architecture assessment in a project. Acknowledgments. This work was supported by: FFG (Austrian Research Promotion Agency) project DECO, no. 846707; FWF (Austrian Science Fund) project APIACE: I 4268.

Assessing Architecture Conformance

19

References 1. Allen, E.B., Gottipati, S., Govindarajan, R.: Measuring size, complexity, and coupling of hypergraph abstractions of software: an information-theory approach. Softw. Qual. J. (2), 179–212. https://doi.org/10.1007/s11219-006-9010-3 2. Allen, E.B., Gottipati, S., Govindarajan, R.: Measuring size, complexity, and coupling of hypergraph abstractions of software: an information-theory approach. Softw. Qual. J. 15, 179–212 (2006) 3. Bansiya, J., Davis, C.G.: A hierarchical model for object-oriented design quality assessment. IEEE Trans. Softw. Eng. 28(1), 4–17 (2002) 4. Basili, V.R., Briand, L.C., Melo, W.L.: A validation of object-oriented design metrics as quality indicators. IEEE Trans. Softw. Eng. 22(10), 751–761 (1996) 5. Bogner, J., Wagner, S., Zimmermann, A.: Towards a practical maintainability quality model for service-and microservice-based systems, pp. 195–198, September 2017 6. Chidamber, S.R., Kemerer, C.F.: A metrics suite for object oriented design. IEEE Trans. Softw. Eng. 20(6), 476–493 (1994) 7. Corbin, J., Strauss, A.L.: Grounded theory research: procedures, canons, and evaluative criteria. Qual. Sociol. 13, 3–20 (1990) 8. Frank, E., Harrell, J.: Regression Modeling Strategies: With Applications to Linear Models, Logistic and Ordinal Regression, and Survival Analysis, 2nd edn. Springer, Heidelberg (2013) 9. Garousi, V., Felderer, M., M¨ antyl¨ a, M.V.: Guidelines for including the grey literature and conducting multivocal literature reviews in software engineering. CoRR 10. Goldstein, M., Moshkovich, D.: Improving software through automatic untangling of cyclic dependencies. In: Association for Computing Machinery, New York, NY, USA (2014) 11. Harrison, R., Counsell, S.J., Nithi, R.V.: An evaluation of the mood set of objectoriented software metrics. IEEE Trans. Softw. Eng. 24(6), 491–496 (1998) 12. Haselb¨ ock, S., Weinreich, R., Buchgeher, G.: Decision models for microservices: design areas, stakeholders, use cases, and requirements. In: Lopes, A., de Lemos, R. (eds.) ECSA 2017. LNCS, vol. 10475, pp. 155–170. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-65831-5 11 13. Hohpe, G., Woolf, B.: Enterprise Integration Patterns. Addison-Wesley, Boston (2003) 14. Lewis, J., Fowler, M.: Microservices: a definition of this new architectural term, March 2004. http://martinfowler.com/articles/microservices.html 15. Newman, S.: Building Microservices: Designing Fine-Grained Systems. O’Reilly, Sebastapol (2015) 16. Pahl, C., Jamshidi, P.: Microservices: a systematic mapping study. In: 6th International Conference on Cloud Computing and Services Science, pp. 137–146 (2016) 17. Pautasso, C., Wilde, E.: Why is the web loosely coupled?: a multi-faceted metric for service design. In: 18th International Conference on World Wide Web, pp. 911–920. ACM (2009) 18. Richardson, C.: A pattern language for microservices (2017). http://microservices. io/patterns/index.html 19. Skowronski, J.: Best practices for event-driven microservice architecture (2019). https://hackernoon.com/best-practices-for-event-driven-microservice-architectur e-e034p21lk

20

E. Ntentos et al.

20. Taibi, D., Lenarduzzi, V.: On the definition of microservice bad smells. IEEE Softw. 35(3), 56–62 (2018) 21. Zdun, U., Navarro, E., Leymann, F.: Ensuring and assessing architecture conformance to microservice decomposition patterns. In: Maximilien, M., Vallecillo, A., Wang, J., Oriol, M. (eds.) ICSOC 2017. LNCS, vol. 10601, pp. 411–429. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-69035-3 29 22. Zimmermann, O.: Microservices tenets. Comput. Sci. - Res. Dev., 301–310 (2016). https://doi.org/10.1007/s00450-016-0337-0 23. Zimmermann, O., Stocker, M., Zdun, U., Luebke, D., Pautasso, C.: Microservice API patterns (2019). https://microservice-api-patterns.org

Formal Software Architectural Migration Towards Emerging Architectural Styles Nacha Chondamrongkul(B) , Jing Sun, and Ian Warren School of Computer Science, University of Auckland, Auckland, New Zealand [email protected], {jing.sun,i.warren}@auckland.ac.nz

Abstract. Software systems are evolved over time to enhance various qualities of the software system by adopting new technologies and principles. The architecture design is usually required to be migrated from one architectural style to another to support this adoption, while the key functionalities still need to be preserved. This paper presents a formal approach that supports architectural migration. Our approach automates refactoring the architectural design to support the exploitation of emerging technologies such as microservices and blockchain. With our approach, the refactored architectural design can be verified to ensure that the essential functional requirements are still preserved, and the design has complied with the behavioural constraints of new architectural styles. We have evaluated the accuracy and performance of our approach. The results prove that it performs reasonably well. Keywords: Software architecture Microservice · Blockchain

1

· Architectural migration ·

Introduction

Emerging technologies and principles have been applied to the software system to enhance the system qualities such as maintainability, scalability and security. Software engineers have been facing challenges to modernise the software system by migrating the existing legacy system to take advantage of new technologies and principles [1], such as continuous software engineering, microservices, containerisation and blockchain. Architectural patterns [13,15,19] have been proposed to give structures of how software architecture should be designed to support new technologies and principles. At the migration, software architecture usually needs to be refactored to convert from an architectural pattern to another [6], while the key functionalities need to be preserved [10]. This paper focuses on the architectural migration that modernises the software system to support emerging technologies [18]. As discussed in Sect. 5, some works [2,7,20] have been proposed to provide guidelines and patterns that support architectural migration. A number of tools [3,9,11,14,17] have been proposed to support this task. However, existing approaches focus either refactoring at the implementation level or supporting particular architectural styles. c Springer Nature Switzerland AG 2020  A. Jansen et al. (Eds.): ECSA 2020, LNCS 12292, pp. 21–38, 2020. https://doi.org/10.1007/978-3-030-58923-3_2

22

N. Chondamrongkul et al.

Moreover, most of the existing tools have not addressed how to ensure that the refactored design would preserve the system functionalities. There is still a lack of approaches that generally support the architectural migration by both refactoring and verifying the architectural design in an automatic manner. This paper presents a formal approach that supports architectural migration by refactoring and verifying the architecture design before the actual system migration can be performed. Our approach applies ontology reasoning and model checking technique. The contribution of this work can be summarised as follows: 1) The formal modelling of software architecture design is proposed to describe the structural and behavioural aspect of architectural design based on architectural styles. 2) A set of generic rules is presented to automate the architectural design refactoring towards new architectural styles that support emerging technologies and principles. 3) The verification approach helps to ensure that key functional requirements are preserved in the refactored design, and the design has complied with the desired architectural styles. 4) We have evaluated the accuracy and performance of our approach with the architectural design of four real-world software systems. The rest of this paper is organised in the following sections. Section 2 shows how to model and refactor software architecture design. Section 3 presents the verification approach and migration benefits. Section 4 presents the evaluation result and the discussion. Section 5 discusses the related approaches in comparison to our approach. This paper is concluded in Section 6.

2

Formal Architectural Migration

The overall process of our approach is shown in Fig. 1. Firstly, the model of current architecture is analysed to identify parts of the design that require changes according to the refactoring rules. The refactoring rules help to select design entities such as connector and component that need to be changed according to the desired architectural styles to be applied. Secondly, the refactoring steps in the rules are performed to create the model of target architecture design. Lastly, the verification has been performed on the model of target architecture design to ensure that the functional requirements are still preserved, and the target architecture design behaves according to the architectural styles. 2.1

Architecture Modelling

As this work focuses on refactoring logical architecture design for the architectural migration, our architecture model is based on Connector and Connector (C&C) view [8]. Both structure and behaviour of architecture design are significant to refactor and verify the architecture design to support desired architectural styles [20]. Therefore, we apply ontology representation in Ontology Web Language (OWL) to capture the structural aspect of architecture design, according to the modelling proposed in [4]. The ontology model is expressive to

Formal Software Architectural Migration

23

1. Identify entities to refactor Current Architecture Design

Architecture Redesigner

Target Architecture Design

Refactoring Rules

2. Perform design refactoring Design Verifier

Verification Result

Functional Requirement

Pattern Constrainst

3. Verify target architecture

Fig. 1. Overall migration process

describe the concepts and their relationship in the knowledge domain. Architectural Description Language (ADL) is used to capture the behavioural aspect of architecture design according to Wright# language proposed in [5]. Wright# is expressive to describe the dynamic behaviour of components and connectors. In the ontology model, the design entities in C&C view such as component, connector, role and port are defined as classes and their relationships are defined as object properties. The components have ports representing its interface. The connector have roles representing parties involved in the interaction. To form the connectivities, ports are attached to one or more roles. The architectural patterns are formally defined to support architectural styles based on this structure. The definition of architectural patterns describes specific structural and behavioural characteristics of different types of component and connector1 . We have formally defined basic architectural patterns such as Client-Server (CS), Publish-Subscribe (PS), and Data Repository (RP). To support modern architectural styles, architectural patterns such as Event-Sourcing (ES) and Command Query Responsibility Segregation (CQRS - CR for command and QR for query) [13] are also defined for event-driven architecture that is commonly used in microservices. Oracle (OR) and Reverse-Oracle (RO) pattern are defined for the blockchain-based architecture [19]. The structure of these architectural patterns can be found in the refactoring rules presented in Sect. 2.2. In this section, we use LifeNet as an illustrative example to present our approach. Figure 2 shows the current architecture design of LifeNet. The components are represented as rectangles and connectors are represented as rounded edged rectangles. LifeNet is a software system that assists patients with Alzheimer’s disease and related dementia. The system allows patients to send an emergency request from his wristband (Lifeband ) that notifies the mobile application for medical staff (Lifeguard ) and caregiver (Lifecare) to help. These requests are verified and handled by SOSGateway and RequestDispatcher component. There are data storage components such as EMCenter and PatientRecord, represented by cylinder box, to allow other components to query and update data. This model 1

The formal architectural patterns can be found at https://bit.ly/2vGv6qi.

24

N. Chondamrongkul et al.

applies three architectural patterns. Client-Server patterns are used for connectors such as soswire and dispatchwire. Publish-Subscribe patterns are used for notiwire connector. Data Repository patterns are used for connectors that query and update data such as emwire and emupwire. Port

responder

requester

Role

LifeBand

writestorage

emupdate

emupwire

soswire

alert

storage

emaccess

pgwire

BackOffice

storage

pgupdate

Hospital Mgmt

publisher notiwire

subscriber writer ptupwire

update writestorage

accept

pgaccess

Practitioner

pgupwire writestorage

responder

Request Dispatcher

reader

writer

dispatchwire

reader

writer

update

requester

emwire

EMCenter

SOS Gateway

sos

Patient Record

gnotify Lifeguard

ptupdate ptaccess

cnotify Lifecare

reader ptwire

storage

Fig. 2. LifeNet’s current design

The structural model of a software system are semantically defined as ontology individuals based on the architectural pattern that are predefined as the ontology class. Due to the page limit, we present some part of the LifeNet model2 . Listing 1.1 shows the definition of Patient component and its ports: ptaccess and ptupdate. ptaccess takes readstorage role of ptwire connector, which allows querying data. ptupdate takes writestorage role to allow updating data. Listing 1.1. LifeNet’s current structural model Individual(ex: Patient value(ex: hasPort ex: ptaccess, ptupdate)) Individual(ex: ptaccess value(ex: hasAttachment ex: readstorage)) Individual(ex: ptupdate value(ex: hasAttachment ex: writestorage)) Individual(ex: ptwire value(ex: hasRole ex: reader,readstorage) 2

The complete model in OWL of LifeNet can be found at https://bit.ly/3bhsCgO.

Formal Software Architectural Migration

25

The behavioural model are defined to describe how the components are executed at runtime to serve the system functionalities. The description of different connector type are defined for the interactive behaviour of architectural patterns. Listing 1.2 shows some part of behavioural model of LifeNet3 . The CSConnector is the definition of a connector type for Client-Server. The components and their port are defined such as LifeBand and SOSGateway. The system scope defines how component are interacting with each other. The connector such as soswire is declared, and used later in the attach statement to define what roles are attached to the component’s port. The execute statement defines what ports are executed during runtime. More details about Wright# can be found in [5]. Listing 1.2. LifeNet’s current behavioural model connector CSConnector { role requester(j) = request -> req!j -> res?j -> process -> Skip; role responder() = req?j -> invoke -> process -> res!j -> responder(); } component LifeBand { port alert() = onalert->alert();} component SOSGateway { port sos() = acknowledge->alert->sos();} system lifenet { declare soswire = CSConnector; attach LifeBand.alert() = soswire.requester(49); attach SOSGateway.sos() = soswire.responder() dispatchwire.requester(19); execute LifeBand.alert() || SOSGateway.sos() ...

2.2

Refactoring Rules

To create the target architecture design, we defines a set of refactoring rules to automate revising the current design. Each refactoring rule consists of ontology definition and refactoring routine. The ontology definition captures the logic to find component or connector that needs to be changed. The refactoring routine is a sequence of steps that can programmatically change the design configuration to support architectural patterns of desired architectural styles. These refactoring rules are generic and can be applied to the architectural design of any software system. The rules presented in this paper focuses on the migration to eventbased and blockchain-based architecture style. They represents the possible rules that cover most well-known cases and are frequently used for migrating basic architectural styles to modern styles. These refactoring rules are as follows: Event Centre. The connector that helps to process events should be changed to Event-Sourcing pattern. The ontology definition aims to select the PublishSubscribe connector (PSConnector) that has an inbound role subscribed to 3

The complete model in ADL of LifeNet can be found at https://bit.ly/2zhLbnN.

26

N. Chondamrongkul et al.

events to process. InboundRole represents any role that waits to be triggered. Below is the ontology definition followed by the refactoring routine. EventCentre ≡ PSConnector  ∃ hasRole (InboundRole  ∃ isAttachOf (Port  EventProcessor )) a) Convert the type of connector to Event-Sourcing pattern (ESConnector) by roles mapping shown in Fig. 3; publisher is changed to event publisher and subscriber is changed to event subscriber. b) Add an component of type EventStore to logs incoming events. c) Connect the connector to the component in step b).





Publisher

Event Source

Event Store

publish

publisher



Subscriber

PSConnector

subscribe

event publisher

evwrite

evpublish event logger



ESConnector

Event Consumer

listen

event subscriber

subscriber

Fig. 3. Mapping of event centre

According to these steps, the LifeNet model can be refactored as shown in Fig. 4 a), the notiwire connector has been converted to Event-Sourcing connector and the RequestLog component is added as an event store component. accept

Request Dispatcher

eventpublisher

notiwire eventsubscriber

gnotify Lifeguard

eventstore

cnotify

a) Event Centre for LifeNet

logem

EMCenter

emaccess

read storage

log

Request Log

Lifecare

emupdate

EMCenter Command

commandstore

emupwire commander BackOffice

pgwire

reader

readstorage Practitioner

update

pgaccess

b) Command & Query for LifeNet

Fig. 4. LifeNet’s refactoring for event-based patterns

Event-Based Command. The connector that transfers the event to persist on a data storage should be converted to a commander in CQRS pattern. The ontology definition selects the repository writing connector (WRConnector) that

Formal Software Architectural Migration

27

is attached to a component, where the events are created and written to the data storage. EventCommand ≡ WRConnector  ∃ hasRole (Writer  ∃ isAttachOf (Port  EventProcessor )) a) Convert the type of connector to CQRS’s command (CRConnector) as shown in Fig. 5; writer and storage role is changed to commander and command store, respectively. b) Add an component of type ViewDB to be a read-only data storage. c) Connect the connector to the component in step b).

Repository Pattern (Write)

CQRS Pattern (Command)



CQRS Pattern (Query)

Repository Pattern (Read)

Command Endpoint Read Endpoint DataReader DataWriter

read write read

issue reader commander data reader read writer

store

QRConnector REConnector WRConnector

readstore CRConnector storage update

store query storage log

command

store Repository

View DB access Command DB

Fig. 5. Mapping of Event-based CQRS

The LifeNet model can be refactored as shown in Fig. 4 b). The emupwire has been converted to a command connector for CQRS pattern and EMCenterCommand has been added as an command store. Event-Based Query. The connector that queries the events persisted on the data storage should be converted to a query processor of CQRS pattern. The ontology definition captures the connector that has an outbound role to query events on a data storage. EventQuery ≡ REConnector  ∃ hasRole (Reader  ∃ isAttachOf (Port  EventProcessor )) a) Convert the type of connector to CQRS’s query (QRConnector) as shown in Fig. 5; data reader and storage role is changed to reader and query role of QRConnector respectively. b) Reroute the connector to the ViewDB component that is a read-only data storage connected to the command connector.

28

N. Chondamrongkul et al.

According to these steps, the LifeNet model can be refactored as shown in Fig. 4 b). The pgwire connector has been converted to query connector for CQRS pattern. This connector links EMCenter as a ViewDB component. Secure Data Writing. The repository component storing data that need to be tamper-proof can be converted to apply blockchain technology. The ontology definition selects the repository component (Repository) that its inbound port InboundPort) is data tampering-proof and write data to the storage. InboundPort represents any port that is attached to the inbound role. SecureDataWriter ≡ Repository  ∃ hasPort(InboundPort  DataTamperingProofPort  ∃ hasAttachmentWriteStorage) a) b) c) d) e) f)

Add an oracle component (Oracle). Attach WriteStorage role to a port of oracle in step a). Add a connector of type IOConnector, which is an Oracle connector. Attach extsupplier role of connector in step c) to the port added in step b). Add a blockchain component (Blockchain). Connect the connector added in step c) to the blockchain component.

According to these steps, the LifeNet model can be refactored as shown in Fig. 6. MedRecord is added as an oracle that connects to a blockchain called MedChain with medupwire connector.

ptupwire

writestorage

extsupplier

medup wire

block storage

medfetch

MedRecord

seclog

Patient Record

blocksupplier MedChain

medshare

medwire

ptaccess

extqurier

Fig. 6. LifeNet’s refactoring to blockchain

Secure Data Reading. The blockchain should be applied at the component that allow data to be queries securely with tampering-proof control applied. The ontology definition selects the repository component (Repository) that its inbound port is data tampering-proof and allow data to be queried. SecureDataReader ≡ Repository  ∃ hasPort(InboundPort  DataTamperingProofPort  ∃ hasAttachmentReadStorage) a) Convert the repository to a reverse oracle component (ReverseOracle) as shown in Fig. 7; access port is changed to blockquery port.

Formal Software Architectural Migration

29

b) Add a connector of type ROConnector, which is a Reverse-Oracle connector. c) Attach a port converted in step a) to the connector in step b). d) Connect the connector added in step b) to the blockchain component.

DataReader

reader read

storage

access

ROConnector extquerier

blocksupplier

Blockchain

blockquery

Repository

blocksupply

REConnector

Reverse Oracle

Repository Pattern

Reverse Oracle Pattern

Fig. 7. Mapping of secure data reading

As shown in Fig. 6 After these steps are applied, the PatientRecord is converted to a reverse oracle. The medwire is added to connect the Medchain that stores patient records on the blockchain.

3

Justification of Architectural Migration

After the architecture design has been refactored, it is verified to ensure that the functional requirements are preserved, and the target design is compiled according to the desired architectural patterns. The model checking technique has been applied to achieve this verification. We also address benefits to the system qualities that can be gained when new architectural styles are applied. 3.1

Verifying Functional Requirements

As the behavioural model has been expressed in ADL, we use Linear Temporal Logic (LTL) to define liveness properties that describe the key functional requirements of the software system. Liveness properties are generally used in the model checking technique to determine whether certain states occur. In this work, we use the liveness property to determine the sequence of events that occurred in the software system. The property (a → ♦b) check whether every event a eventually leads to event b). According to the modelling proposed in [5], the events triggered from the ports are labelled as [Comp.Prt.Evt], where Comp is name of a component, Prt is name of a port and Evt is name of event. The events triggered by the roles are labelled as [Comp.Conn.Rle.Evt], where Conn is name of a connector, Rle is name of a role and Evt is name of event. The following shows the functional properties that are defined for LifeNet.

30

N. Chondamrongkul et al. (1) (SOSGateway.sos.acknowledge → ♦LifeBand.alert.onalert) (2) (RequestDispatcher .accept.dispatched → ♦SOSGateway.sos.acknowledge) (3) (RequestDispatcher .accept.dispatched → ♦EMCenter .emaccess.emaccessed) (4) (Lifeguard.gnotify.acknowledge → ♦Patient.ptaccess.ptaccessed) (5) (Lifecare.cnotify.acknowledge → ♦Patient.ptaccess.ptaccessed)

These properties can be explained as follows: (1) When the emergency is requested, the request is acknowledged and the wristband’s status is switched to alert mode, (2) After the emergency request is dispatched to process, the request is acknowledged by the system, (3) After the request is dispatched to process, the system must find the emergency center in the proximity of patient location, (4) After the emergency staff acknowledges the emergency request (through Lifeguard application), the patient record can be fetched and verified, (5) After the caregiver acknowledges the emergency request (through Lifecare application), the patient record can be fetched and verified. These functional requirement properties describe how the system should respond to the emergency request. They are specific to the software system and have been proved valid on the model of current architecture design. The same set of properties are used to verify the model of target architecture design. If the verification results are proved valid, the key functional requirements are preserved. We used PAT [16] as a model checker to make a verification in this work. Below are some part of the verification results. All properties above are proved valid after we verified them against the behavioural model of the target architecture of LifeNet. In other words, the target architecture design is proved to support all key functionalities that the current design has. ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ Verification Result ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ The Assertion (lifenet() |= 2(SOSGateway sos ... is VALID. The Assertion (lifenet() |= 2(RequestDispatcher accept ... is VALID.

3.2

Checking Architectural Pattern Constraints

The liveness properties are defined to describe the behavioural constraints of the architectural pattern. Each refactoring rules has a corresponding constraint defined as the following formulas. (1) ([EventPublisher ].[Prt].[Event] → ♦[EventStore].[EventCentre].eventstore.persist) (2) ([EventCommander ].[Prt].[Event] → ♦[CommandStore].[EventCommand].commandstore.process) (3) ([EventReader ].[Prt].[Event] → ♦[ViewDB].[EventQuery].readstore.process) (4) ([Oracle].[Prt].[Event] → ♦[Blockchain].[Conn].blockstorage.stored) (5) ([Blockchain].[Conn].blocksupplier .process → ♦[ReverseOracle].[Prt].[Event])

Formal Software Architectural Migration

31

Formula (1) for the Event Centre rule checks the behaviour of an EventSourcing connector EventCentre. This constraint ensures that every event is logged in the event store. EventPublisher is a component that its port (Prt) is attached to the event publisher role. EventStore represent the component that connects to the EventCentre connector. The eventstore.persist are role and event predefined for the architectural pattern. Formula (2) is for the Event-based Command rule. It ensures that every incoming command logged in the command store. EventCommander is a component that its port (Prt) is attached to the event commander role. CommandStore represents a component that connects to the EventCommand connector. Formula (3) is for the Event-based Query rule. It checks if the event can be queried from the view storage. EventReader is a component that its port is attached to the reader role. ViewDB is read-only storage. Formula (4) is for the Secure Data Writing rule. It ensures that the data can be stored on the blockchain according to Oracle pattern. Oracle is an oracle component added to the system. Blockchain represents a blockchain component and Conn represents a Oracle connector. Formula (5) is for Secure Data Writing rule. Blockchain represents a blockchain component and Conn represent a Reverse-Oracle connector. ReverseOracle is a Reverse-Oracle component. To verify the target architecture design of LifeNet, below are properties that are defined according to the formulas, respectively. After we have verified these properties defined for the architectural constraints, the results are given as valid for all properties. These results prove that the target architecture design has complied with the desired architectural patterns. (1) (RequestDispatcher .accept.dispatched → ♦RequestLog.reqwire.eventstore.persist) (2) (BackOffice.updateprofile.updating → ♦EmCenterCommand .emupwire.commandstore.process) (3) (EmCenter .emaccess.emaccessed → ♦Practitioner .pgwire.readstore.process) (4) (MedRecord .seclog.ptcommit → ♦MedChain.medupwire.blockstorage.stored ) (5) (MedChain.medwire.blocksupplier .process → ♦Patient.ptaccess.ptaccessed )

3.3

Benefits of the Migration

After the architecture designs of subject systems have been migrated to support new architectural styles, the target architecture designs generally gain the following attributes. Maintainability. The event-based architecture style has been applied to mitigate cohesive interdependencies among components that are in the current architecture. This style changes component’s reliance on service of another to the events. In the target architecture designs, components can, therefore, be independently modified, deployed and restored. In LifeNet, after Event-Sourcing pattern has applied to notiwire connector as shown in Fig. 4 a), RequestDispatcher

32

N. Chondamrongkul et al.

chronologically stores all requests on the RequestLog. If the RequestDispatcher failed or went off-line, the restoration of system state can always be done by restoring the component’s execution based on the requests logged in the RequestLog. Scalability. As the target design embrace the loosely-coupled principle, each component can be self-contained in the container that allows the component to be deployed and executed individually. A prominence implementation of containers is Docker. Docker container is supported by tools like Kubernetes that can automatically scale the containers. In LifeNet, after the design has been refactored according to CQRS pattern as shown in Fig. 4 b), the query and update operation performs on separate storages; EMCenterCommand for logging update operation and EMCenter for query only. This enables us to optimise the read operation on EMCenter by caching or clustering to support higher loads. This optimisation can be achieved with less computational resources than traditional data repository. Availability. The data repositories become decentralised as the data are replicated dispersedly on blockchain nodes. The decentralisation enhances the availability of data access, as there is no single point of failure. When a node fails, the data can be accessible through other available nodes. The transactions on data are also transparent, as the users with provided authority can always view the transaction. In the refactored design of LifeNet shown in Fig. 6, as the patient records are stored on MedChain, the data are replicated on every nodes joining in the blockchain network. If a node managed by a hospital fails, the data can be fetched or recovered from other nodes. Also, the patient records can be fetched and traced by any hospital that joins this blockchain. Data-Tampering Proof. In term of security, the data structure in the blockchain is append-only, so data cannot be deleted or altered. The consensus of all the ledger participants is required to record data in the blockchain. As the target architecture design applies the architectural patterns that support the interaction to the blockchain, sufficient security control is required to secure the components that have direct communication with the blockchain network. In the refactored design of LifeNet, updating data requires a consensus among hospitals in the networks, so data can only be updated through nodes in the blockchain network by MedRecord component. Therefore, MedRecord must apply security controls such as authorisation and firewall to prevent malicious traffic.

4

Evaluation

This evaluation aims to assess the accuracy and performance of our approach. As there is no benchmark set to evaluate our approach, the architectural design of four real-world software systems are selected to create the models used in this evaluation, namely AgriDigital (AD), Life Net (LN), Sock Shop (SS), Supply Chain (SC). The details of their current architecture design are shown in Table 1. The Cur.Ptn. Column denotes the architectural patterns that are applied in the

Formal Software Architectural Migration

33

current architecture designs. Tgt. Ptn. denotes the patterns that of the target architecture designs to apply. The C&C column shows the number of component and connector. The Req column shows the number of key functional requirements that have been used to verify the design. The current architecture design of these systems is based on the monolithic architecture that needs the migration to the event-based microservice architecture to embrace loosely-coupling principle. Also, some data are to be securely persisted on the blockchain. Table 1. Subject systems System

Cur. Ptn.

Agri Digital Agriculture asset tracking system

CS, PS, RP OR, RO, ES

20

5

Life Net Medical emergency system

CS, PS, RP OR, RO, ES, CR, QR 19

5

Sock Shop E-Commerce System

CS, RP

CR, QR

22

5

Supply Chain Business process management

CS, RP

OR, RO

18

6

4.1

Tgt. Ptn.

C&C Req

Experiment Setup

This evaluation aims at assessing the completeness and soundness of the refactoring rules, and has been conducted according to the following process. Firstly, we defined the models of current architecture design and functional requirements using ArchModeller4 . ArchModeller is a graphical user interface that allows users to seamlessly draw a graphical diagram for software architecture design and make a verification. The tool can automatically converts graphical diagrams into the models in OWL and ADL for the verification. Secondly, all five refactoring rules have been implemented in the tool to refactor the current architecture model and create the target architecture model5 . Thirdly, the functional requirement properties have been used to verify the target architecture model. Fourthly, we defined the pattern constraint properties to verify the target architecture model. Lastly, we have gathered the verification results to determine the completeness and soundness of refactoring rules. Each rule is assessed by the combination of verification result of its pattern constraints property and all functional requirement properties. If the functional requirements properties have any invalid result, the refactoring routine alters the system in the way that it incorrectly performs functionalities. If the pattern-constraint property is proved invalid, the refactoring routine may consist of steps that incorrectly refactor the design, according to the architectural pattern. The properties that are proved valid are considered as true-positive (Tpos ), and invalid properties are considered as false-positive 4 5

Arch Modeller can be found at http://bit.ly/2m3LITT. The implementation of refactoring rules can be found at https://bit.ly/2WEHaTw.

34

N. Chondamrongkul et al.

(Fpos ). We also manually verified the target architecture design to find the falsenegative (Fneg ) result that is any part of the design that requires refactoring but not covered by the refactoring rules. Below is how we calculated the measurements, namely precision and recall that were used to evaluate the soundness and completeness of our approach. Precision =

Tpos Tpos + Fpos

Recall =

Tpos Tpos + Fneg

To assess the performance of our approach, we gathered the performance statistic of the properties verification against the models of target architecture design. The performance statistics include processing time in milliseconds and the number of visited states. This performance evaluation was carried out using an Intel Core i7-7500U CPU @ 2.7 GHz with 8.00 GB Ram computer. 4.2

Evaluation Result

The result of accuracy evaluation6 has been summarised in Table 2. This table classifies the results according to the rules presented in Sect. 2.2. The ptn denotes the verification result of pattern constraint properties. The fnc denotes the verification result of functional requirement properties. The numbers that are shown in ptn and fnc column are the precision rate; - means that the rule is not used in that system, as not all patterns are applied to the design. The msn column indicates the false-negative result as the number of the entities that need refactoring but not yet refactored. Overall, all refactoring rules have the precision rate of 100%. The recall rates are also 100% as we have not found any false-negative result. Table 2. Evaluation results Rule

AD

LN

SS

SC

ptn fnc msn ptn fnc msn ptn fnc msn ptn fnc msn #1 Event Centre

1.0 1.0 0

1.0 1.0 0

–

–

–

–

–

1.0 1.0 0

1.0 1.0 0

–

–

–

1.0 1.0 0

1.0 1.0 0

–

–

–

1.0 1.0 0

–

–

–

1.0 1.0 0

–

–

–

1.0 1.0 0

#2 Event Command –

–

–

#2 Event Query

–

–

–

#4 Secure Write

1.0 1.0 0

#5 Secure Read

1.0 1.0 0

1.0 1.0 0

–

The result of the performance evaluation is presented in Fig. 8. This graph illustrates the verification performance of LifeNet model, as it applies all five refactoring rules. The properties prop1 to prop5 are functional requirement properties, while const1 to const5 are the pattern constraint properties. The 6

The models and evaluation results can be found at https://bit.ly/3ft3gQv.

Formal Software Architectural Migration

35

verification generally took less than 0.3 s. The processing times for the verification of functional requirements have no significant difference. The const2 that was used to verify the event command of CQRS pattern took the most processing time, while the const5 that was used to verify the Reverse-Oracle pattern took the least processing time. We have found the same trend in the other models. 4.3

Discussion

According to the evaluation result, the refactoring rules have been proved to be soundness as they have been used to refactor the subject systems, while their key functional requirements are still preserved. As all design entities that require changes are refactored, our refactoring rules are proved to be complete. However, this evaluation focuses on the migration to only event-based microservice and blockchain-based architecture, so the migration to other architectural styles requires more refactoring rules to be defined by software architect. The verification performance is acceptable for the size of model used in this evaluation, however more comprehensive evaluation needs to be conducted to better understand how it performs with different sizes of model.

Fig. 8. Performance result

Other advantages of our approach are with the formal modelling of software architecture design. As the formal model facilitates the application of formal techniques, the ontology reasoning and model checking can be extended to support other aspects of verification. For example, the ontology definition can be defined to represent the security characteristics that measure and compare security between current and target architecture designs. Also, the model checking technique can be used to trace different execution scenarios to determine security vulnerability or design flaws.

5

Related Work

Fowler [7] presented a principle of how we can refactor the source code to eliminate design flaws. Most of these design flaws pose difficulties in maintaining the software system. Luca et al. [14] and Yun et al. [11] proposed automated

36

N. Chondamrongkul et al.

approaches that suggest refactoring plans using search-based algorithm. However, these tools are performed on the source code and rely on the user feedback, unlike our approach that focuses at the architectural design level and rely on the formal logics. Tanhaei et al. [17] presented a framework for refactoring the architecture of software product lines (SPLs). Their approach aims to keep SPLs consistent with the feature model consisted of a set of similarities and differences. However, this approach requires a custom algorithm to reason and check the models, unlike our approach that is based on standard techniques such as ontology reasoning and model checking. Some guidelines such as Zimmermann [20], [2] have been proposed to support the migration to modern architecture style such as microservice and cloud-based software system. Holmes and Zdun [9] proposed an automated architectural refactoring approach for security and availability requirements. Their approach has applied formalised architectural knowledge in model verification and transformation. Their work focuses particularly on the infrastructure of cloud application, while our approach generally focuses on the logical view of architecture design with different architectural styles. Nunes et al. [12] proposed a complete workflow to support the migration to microservice architecture. Their approach applies the static analysis of the source code that is limited to a development framework. Bucchiarone et al. [3] proposed a model-driven approach for the automatic migration to microservice architecture. A meta-programming framework has been applied to transform the source code and generate the container configuration; however, it does not address how to ensure that the migrated system would correctly operate. Overall, none of the existing works proposes a set of generic rules that support restructuring and verifying the design based on the architectural style. The architectural styles allow technologies to be exploited in the system implementation to take various advantages, as discussed in Sect. 3.3. Also, none has proposed to apply the formal technique to verify the target architecture design, so it is difficult to extend the verification to check other properties as the existing approaches rely on custom algorithms hard-coded in the tools. The verification in our approach can be extended by defining liveness property in LTL to describe other functional requirements or architectural pattern constraints.

6

Conclusion

In this paper, we introduce the formal approach to support architectural migration towards emerging architectural styles. A set of generic rules has been proposed to automate the refactoring and checking the architectural design according to the functional requirements and architectural styles. The verification ensures that the key functional requirements are still preserved after the design has been changed. Also, it ensures that the migrated system behaves according to the desired architectural styles. With the new architectural styles applied, new technologies can be exploited at the system implementation to enhance the system’s qualities. The evaluation has proved that the refactoring rules are valid and practical to perform architectural migration for the subject systems.

Formal Software Architectural Migration

37

As architectural migration is a part of system migration, we will extend this approach to automatically plan incremental migration steps that support system migration towards the target architecture.

References 1. Balalaie, A., Heydarnoori, A., Jamshidi, P.: Migrating to cloud-native architectures using microservices: an experience report. In: Celesti, A., Leitner, P. (eds.) ESOCC Workshops 2015. CCIS, vol. 567, pp. 201–215. Springer, Cham (2016). https://doi. org/10.1007/978-3-319-33313-7 15 2. Balalaie, A., Heydarnoori, A., Jamshidi, P., Tamburri, D., Lynn, T.: Microservices migration patterns. Softw.: Pract. Exp. 48, 2019–2042 (2018) 3. Bucchiarone, A., Soysal, K., Guidi, C.: A model-driven approach towards automatic migration to microservices. In: Bruel, J.-M., Mazzara, M., Meyer, B. (eds.) DEVOPS 2019. LNCS, vol. 12055, pp. 15–36. Springer, Cham (2020). https://doi. org/10.1007/978-3-030-39306-9 2 4. Chondamrongkul, N., Sun, J., Warren, I.: Ontology-based software architectural pattern recognition and reasoning. In: 30th International Conference on Software Engineering and Knowledge Engineering (SEKE), pp. 25–34, June 2018 5. Chondamrongkul, N., Sun, J., Warren, I.: PAT approach to architecture behavioural verification. In: 31th International Conference on Software Engineering and Knowledge Engineering, pp. 187–192, July 2019 6. Ford, N., Parsons, R., Kua, P.: Building Evolutionary Architectures: Support Constant Change. O’Reilly Media Inc., Sebastopol (2017) 7. Fowler, M.: Refactoring: Improving the Design of Existing Code. A Martin Fowler Signature Book. Addison-Wesley, Boston (2019) 8. Garlan, D., et al.: Documenting Software Architectures: Views and Beyond, 2nd edn. Addison-Wesley Professional, Boston (2010) 9. Holmes, T., Zdun, U.: Refactoring architecture models for compliance with custom requirements. In: Proceedings of the 21th ACM/IEEE MODELS 2018, pp. 267– 277. Association for Computing Machinery, New York (2018) 10. Klettke, M., Thalheim, B.: Evolution and migration of information systems. In: Embley, D., Thalheim, B. (eds.) Handbook of Conceptual Modeling, pp. 381–419. Springer, Heidelberg (2011). https://doi.org/10.1007/978-3-642-15865-0 12 11. Lin, Y., Peng, X., Cai, Y., Dig, D., Zheng, D., Zhao, W.: Interactive and guided architectural refactoring with search-based recommendation. In: Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering FSE 2016, pp. 535–546. Association for Computing Machinery, New York (2016) 12. Nunes, L., Santos, N., Rito Silva, A.: From a monolith to a microservices architecture: an approach based on transactional contexts. In: Bures, T., Duchien, L., Inverardi, P. (eds.) ECSA 2019. LNCS, vol. 11681, pp. 37–52. Springer, Cham (2019). https://doi.org/10.1007/978-3-030-29983-5 3 13. Richards, M.: Software Architecture Patterns. O’Reilly Media Inc., Sebastopol (2015) 14. Rizzi, L., Fontana, F.A., Roveda, R.: Support for architectural smell refactoring. In: Proceedings of the 2nd International Workshop on Refactoring IWoR 2018, pp. 7–10. Association for Computing Machinery, New York (2018) 15. Stopford, B.: Designing Event-Driven Systems. O’Reilly, Sebastopol (2018)

38

N. Chondamrongkul et al.

16. Sun, J., Liu, Y., Dong, J.S., Chen, C.: Integrating specification and programs for system modeling and verification. In: Proceedings of the Third IEEE International Symposium on Theoretical Aspects of Software Engineering (TASE 2009), pp. 127–135. IEEE Computer Society (2009) 17. Tanhaei, M., Habibi, J., Mirian-Hosseinabadi, S.H.: A feature model based framework for refactoring software product line architecture. J. Comput. Sci. Technol. 31, 951–986 (2016) 18. Ulrich, W.: Introduction to architecture-driven modernization. In: Ulrich, W.M., Newcomb, P.H. (eds.) Information Systems Transformation, pp. 3–34. The MK/OMG Press, Morgan Kaufmann, Boston (2010) 19. Xu, X., Pautasso, C., Zhu, L., Lu, Q., Weber, I.: A pattern collection for blockchainbased applications. In: Proceedings of the 23rd European Conference on Pattern Languages of Programs EuroPLoP 2018. Association for Computing Machinery, New York (2018) 20. Zimmermann, O.: Architectural refactoring for the cloud: a decision-centric view on cloud migration. Computing 99, 129–145 (2017)

Monolith Migration Complexity Tuning Through the Application of Microservices Patterns Jo˜ao Franscisco Almeida and Ant´ onio Rito Silva(B) INESC-ID/Department of Computer Science and Engineering, Instituto Superior T´ecnico, Av. Rovisco Pais 1, 1049-001 Lisbon, Portugal {joao.santos.almeida,rito.silva}@tecnico.ulisboa.pt

Abstract. The microservices architecture has become mainstream for the development of business applications because it supports the adaptation of scalability to the type of demand, but, most importantly, because it fosters an agile development process based on small teams focused on the product. Therefore, there is the need to migrate the existing monolith systems to microservices. Current approaches to the identification of candidate microservices in a monolith neglect the cost of redesigning the monolith functionality due to the impact of the CAP theorem. In this paper we propose a redesign process, guided by a set of complexity metrics, that allows the software architect to analyse and redesign the monolith functionality given a candidate decomposition. Both, the redesign process and the metrics are evaluated in the context of candidate decompositions of two monolith systems. Keywords: Microservices architecture · Monolith migration Complexity metrics · Microservices patterns

1

·

Introduction

Microservices architecture emerged due to the need to have highly available and scalable systems that can be developed by multiple teams in an agile environment. This is achieved through the definition of independently deployable distributed systems, implemented around business capabilities. As the monolith application size increases, it imposes several drawbacks as the lack of agility, modifiability and deployablity. As a consequence there is the need to migrate monolith systems to a microservices architecture. However, this transition imposes a cost because the application cannot preserve the behavior that existed in the monolith. This is due to the introduction of distributed transactions, as the monolith functionalities will be implemented through multiple independent microservices (transactions). Therefore, transaction management is more complex in a microservice architecture because transactions cannot be executed according to the ACID (Atomicity, Consistency, Isolation, Durability) properties, which introduces extra complexity for developers c Springer Nature Switzerland AG 2020  A. Jansen et al. (Eds.): ECSA 2020, LNCS 12292, pp. 39–54, 2020. https://doi.org/10.1007/978-3-030-58923-3_3

40

J. F. Almeida and A. R. Silva

to handle. This extra complexity is explained by the CAP theorem [6], where the decision to maintain the same level of consistency as in a monolith can only be achieved through the application of a two-phase commit protocol, which does not scale with many local transactions. To solve this problem, the use of sagas [5] was suggested, in the context of the microservices architecture [11,13], as the main alternative to the two-phase commit protocol to handle distributed transactions. On the other hand, the API Gateway pattern has been proposed [11,13] to implement queries in a distributed system. The SAGA pattern can be applied to functionalities that create or update data, and consist in dividing a transaction in multiple local transactions, where each local transaction is executed inside a single service following the ACID properties. A saga can have two different structures: (1) choreography where the decision and sequencing is distributed through the saga participants, or (2) orchestration, where the decision and sequencing is decided in one orchestractor class, inside a cluster. Independently of the structure, the usage of sagas can guarantee the properties atomicity, consistency, and durability but cannot ensure the isolation property [13]. The lack of isolation can generate anomalies such as: (1) lost updates - when a saga overwrites data without reading changes performed by others sagas, (2) dirty reads - when a saga reads data changed by others sagas that have not been committed, (3) nonrepeatable reads - a saga reads the same data twice and gets different results. To correct this anomalies there is a set of countermeasures that can be applied. One of them is the semantic lock that corrects these errors by creating intermediate states as application-level locks that indicate if an entity was written by one saga, alerting others concurrent sagas to these events. It can be integrated with the SAGA pattern typically indicating the current saga state. Because now all the functionalities must be aware of the semantic lock, this imposes extra complexity to the functionalities design and implementation. It also adds complexity to queries, that have to handle the possible combination of semantic locks of the data that they are integrating. Due to the lack of isolation, the saga local transactions can be of three types: (1) pivot - a transaction that if succeeds then the saga is going to succeed; (2) retriable - transactions that occur after the pivot transactions, do not rollback; and (3) compensatable - the transactions that may have to rollback. In a saga there is at most one pivot transaction, and all transactions that are not retriable nor the pivot transaction, are compensatable. In previous work [12,14], a tool was developed that collects information from monolith systems and, based on similarity measures, suggests a microservice candidate decomposition. Its level of complexity can be assessed through a complexity metric that determines the decomposition complexity based on the mean of its functionalities complexity. This metric calculates the impact that the relaxing of atomic transactional behaviour has on the redesign and implementation of the functionalities. In this paper we leverage on the previous work by, given a decomposition and a complexity value, support the redesign of the functionalities and queries, applying the SAGA and the API Gateway patterns, while

Monolith to Microservices

41

the complexity value is tuned, because there is more precise information on the decomposition. With our approach we intend to answer the following questions: – RQ1. What set of operations can be provided to the architect such that the functionalities can be redesigned by applying the SAGA pattern? – RQ2. Is it possible to refine the complexity value associated with the monolith migration when there is additional information about the functionalities redesign? This paper makes two contributions. First, we define a set of operations that the architect can apply to the initial execution flow of a monolith functionality, such that it can be transformed in a microservices execution flow based on the SAGA pattern. Second, we define new metrics that provide a more precise value on the cost of the migration, due to the inclusion of the information about the application of the SAGA pattern. In the next section we present the set of operations used in the redesign. In Sect. 3 we present the new complexity metrics. In Sect. 4 we evaluate our work in the context of two monolith systems. Section 5 addresses the related work and Sect. 6 the conclusions.

2

Functionality Redesign

Definition: Monolith. A monolith is a pair (F, E), where F represents its set of functionalities, the functionalities are represented with lower case f , and E represents its set of domain entities, which are accessed by the functionalities, the domain entities are represented with lower case e. The entities are accessed by the functionalities in two modes, read and write. Therefore, M = {r, w} represents the access modes in a monolith, and an access is a pair domain entity access mode, represented by (e, m). The accesses of a functionality f are represented as a sequence of accesses s, where S represents all the sequences of accesses done in the monolith by its functionalities to the domain entities, f.sequence denotes the sequence of access of functionality f , s.entities denotes the entities accessed in sequence s. It is also defined the auxiliary function entities(s : S, m : M ) : 2E , as entities(s, m) = {e ∈ E : (e, m) ∈ s}, which returns the entities accessed in s in mode m. When a monolith is decomposed into a set of candidate microservices, each candidate microservice is a cluster of domain entities. Definition: Monolith Decomposition. A monolith decomposition into a set of candidate microservices is defined by a set of clusters C of the monolith domain entities, where each cluster c represents a candidate microservice and c.entities denotethe domain entities in cluster c, such that all domain entities are in a cluster, c∈C c.entities = E, and in a single one, ∀ci =cj ∈C ci .entities ∩ cj .entities = ∅.

42

J. F. Almeida and A. R. Silva

Given e ∈ E and a decomposition C, e.cluster denotes the entity’s cluster, and given a set of entities E  ⊆ E, E  .cluster = {c ∈ C : ∃e∈E  e ∈ c.entities} denotes its set of entities clusters. Given a monolith candidate decomposition, the monolith functionalities are decomposed into a set of local transactions, where each local transaction corresponds to the ACID execution of part of the functionality domain entity accesses in the context of a candidate microservice. Definition: Functionality Decomposition. A monolith functionality f is decomposed, in the context of a candidate decomposition C, by a sequence of sequences of access to domain entities, denoted by f.subsequences, where all domain entities in a subsequence are in the same cluster, ∀s∈f.subsequences ∃c∈C : s.entities ⊆ c.entities, two consecutive subsequences occur in different clusters, ∀0≤i