{"Affiliation":[{"label":"Affiliation","value":"Science, Faculty of","attrs":{"lang":"en","ns":"http:\/\/vivoweb.org\/ontology\/core#departmentOrSchool","classmap":"vivo:EducationalProcess","property":"vivo:departmentOrSchool"},"iri":"http:\/\/vivoweb.org\/ontology\/core#departmentOrSchool","explain":"VIVO-ISF Ontology V1.6 Property; The department or school name within institution; Not intended to be an institution name."},{"label":"Affiliation","value":"Computer Science, Department of","attrs":{"lang":"en","ns":"http:\/\/vivoweb.org\/ontology\/core#departmentOrSchool","classmap":"vivo:EducationalProcess","property":"vivo:departmentOrSchool"},"iri":"http:\/\/vivoweb.org\/ontology\/core#departmentOrSchool","explain":"VIVO-ISF Ontology V1.6 Property; The department or school name within institution; Not intended to be an institution name."}],"AggregatedSourceRepository":[{"label":"Aggregated Source Repository","value":"DSpace","attrs":{"lang":"en","ns":"http:\/\/www.europeana.eu\/schemas\/edm\/dataProvider","classmap":"ore:Aggregation","property":"edm:dataProvider"},"iri":"http:\/\/www.europeana.eu\/schemas\/edm\/dataProvider","explain":"A Europeana Data Model Property; The name or identifier of the organization who contributes data indirectly to an aggregation service (e.g. Europeana)"}],"Campus":[{"label":"Campus","value":"UBCV","attrs":{"lang":"en","ns":"https:\/\/open.library.ubc.ca\/terms#degreeCampus","classmap":"oc:ThesisDescription","property":"oc:degreeCampus"},"iri":"https:\/\/open.library.ubc.ca\/terms#degreeCampus","explain":"UBC Open Collections Metadata Components; Local Field; Identifies the name of the campus from which the graduate completed their degree."}],"Creator":[{"label":"Creator","value":"Akamoto, Shizuko","attrs":{"lang":"en","ns":"http:\/\/purl.org\/dc\/terms\/creator","classmap":"dpla:SourceResource","property":"dcterms:creator"},"iri":"http:\/\/purl.org\/dc\/terms\/creator","explain":"A Dublin Core Terms Property; An entity primarily responsible for making the resource.; Examples of a Contributor include a person, an organization, or a service."}],"DateAvailable":[{"label":"Date Available","value":"2023-08-21T21:03:01Z","attrs":{"lang":"en","ns":"http:\/\/purl.org\/dc\/terms\/issued","classmap":"edm:WebResource","property":"dcterms:issued"},"iri":"http:\/\/purl.org\/dc\/terms\/issued","explain":"A Dublin Core Terms Property; Date of formal issuance (e.g., publication) of the resource."}],"DateIssued":[{"label":"Date Issued","value":"2023","attrs":{"lang":"en","ns":"http:\/\/purl.org\/dc\/terms\/issued","classmap":"oc:SourceResource","property":"dcterms:issued"},"iri":"http:\/\/purl.org\/dc\/terms\/issued","explain":"A Dublin Core Terms Property; Date of formal issuance (e.g., publication) of the resource."}],"Degree":[{"label":"Degree (Theses)","value":"Master of Science - MSc","attrs":{"lang":"en","ns":"http:\/\/vivoweb.org\/ontology\/core#relatedDegree","classmap":"vivo:ThesisDegree","property":"vivo:relatedDegree"},"iri":"http:\/\/vivoweb.org\/ontology\/core#relatedDegree","explain":"VIVO-ISF Ontology V1.6 Property; The thesis degree; Extended Property specified by UBC, as per https:\/\/wiki.duraspace.org\/display\/VIVO\/Ontology+Editor%27s+Guide"}],"DegreeGrantor":[{"label":"Degree Grantor","value":"University of British Columbia","attrs":{"lang":"en","ns":"https:\/\/open.library.ubc.ca\/terms#degreeGrantor","classmap":"oc:ThesisDescription","property":"oc:degreeGrantor"},"iri":"https:\/\/open.library.ubc.ca\/terms#degreeGrantor","explain":"UBC Open Collections Metadata Components; Local Field; Indicates the institution where thesis was granted."}],"Description":[{"label":"Description","value":"Microservice architectures are a popular approach for modernizing legacy monolithic systems. However, transforming an existing monolith into microservices is a complex task for developers. In practice, developers typically perform the decomposition iteratively, extracting one service at a time. Unfortunately, most existing tools do not adequately support such extraction tasks, as they aim to transform a monolith into microservices architecture at once. This paper presents Extract, a prototype tool that aligns with the developer's individual workflow for performing a single microservice extraction task. Extract empowers developers to analyze the particular classes and methods within the monolith that they intend to migrate to a new microservice. Moreover, it offers human-in-the-loop support, allowing developers to make well-informed decisions regarding the extraction process and explore alternative designs. We evaluate Extract with four case studies involving open-source monolithic applications. These studies serve to demonstrate how the approach aids developers in making practical decisions during the extraction process. Furthermore, we compare the outcomes of Extract's service designs with manually decomposed microservices for further analysis.","attrs":{"lang":"en","ns":"http:\/\/purl.org\/dc\/terms\/description","classmap":"dpla:SourceResource","property":"dcterms:description"},"iri":"http:\/\/purl.org\/dc\/terms\/description","explain":"A Dublin Core Terms Property; An account of the resource.; Description may include but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource."}],"DigitalResourceOriginalRecord":[{"label":"Digital Resource Original Record","value":"https:\/\/circle.library.ubc.ca\/rest\/handle\/2429\/85558?expand=metadata","attrs":{"lang":"en","ns":"http:\/\/www.europeana.eu\/schemas\/edm\/aggregatedCHO","classmap":"ore:Aggregation","property":"edm:aggregatedCHO"},"iri":"http:\/\/www.europeana.eu\/schemas\/edm\/aggregatedCHO","explain":"A Europeana Data Model Property; The identifier of the source object, e.g. the Mona Lisa itself. This could be a full linked open date URI or an internal identifier"}],"FullText":[{"label":"Full Text","value":"Extract: Informing Microservice Extraction DecisionsFrom the Bottom-upbyShizuko AkamotoBSc. Computer Science, University of British Columbia, 2021A THESIS SUBMITTED IN PARTIAL FULFILLMENTOF THE REQUIREMENTS FOR THE DEGREE OFMaster of ScienceinTHE FACULTY OF GRADUATE AND POSTDOCTORALSTUDIES(Computer Science)The University of British Columbia(Vancouver)August 2023\u00a9 Shizuko Akamoto, 2023The following individuals certify that they have read, and recommend to the Fac-ulty of Graduate and Postdoctoral Studies for acceptance, the thesis entitled:Extract: Informing Microservice Extraction DecisionsFrom the Bottom-upsubmitted by Shizuko Akamoto in partial fulfillment of the requirements for thedegree of Master of Science in Computer Science.Examining Committee:Reid Holmes, Professor, Computer Science, UBCSupervisorElisa Baniassad, Professor of Teaching, Computer Science, UBCSupervisory Committee MemberiiAbstractMicroservice architectures are a popular approach for modernizing legacy mono-lithic systems. However, transforming an existing monolith into microservices is acomplex task for developers. In practice, developers typically perform the decom-position iteratively, extracting one service at a time. Unfortunately, most existingtools do not adequately support such extraction tasks, as they aim to transform amonolith into microservices architecture at once. This paper presents Extract, aprototype tool that aligns with the developer\u2019s individual workflow for perform-ing a single microservice extraction task. Extract empowers developers to analyzethe particular classes and methods within the monolith that they intend to migrateto a new microservice. Moreover, it offers human-in-the-loop support, allowingdevelopers to make well-informed decisions regarding the extraction process andexplore alternative designs. We evaluate Extract with four case studies involvingopen-source monolithic applications. These studies serve to demonstrate how theapproach aids developers in making practical decisions during the extraction pro-cess. Furthermore, we compare the outcomes of Extract\u2019s service designs withmanually decomposed microservices for further analysis.iiiLay SummaryThis paper discusses the challenge of modernizing an legacy monolithic systemusing microservices architecture. Typically, developers break down the monolithinto smaller services, one at a time. Existing tools fall short in supporting step-by-step decomposition, complicating the decomposition process. To address this,the paper introduces Extract, an iterative decomposition tool. Extract facilitatesdevelopers to choose components for extraction and provides informed decision-making guidance. We evaluated the tool with four case studies using open-sourcemonolithic applications. Extract enabled the developer to make practical extractiondecision and produced service designs that are comparable to manually-performeddecomposition.ivPrefaceThe work presented in this thesis was conducted in the Software Practices Labora-tory at the University of British Columbia, Point Grey campus.Shizuko Akamoto was the lead investigator, responsible for concept formation,implementation, case studies, and result analysis. Reid Holmes was the supervisoryauthor on this work and was involved throughout all stages of the project.vTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiiLay Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1 Automated Monolith Decomposition . . . . . . . . . . . . . . . . 42.2 Feature-Oriented Dependency Analysis . . . . . . . . . . . . . . 62.3 Support for Decision Making . . . . . . . . . . . . . . . . . . . . 72.4 Visualizing Structural Dependencies . . . . . . . . . . . . . . . . 83 Microservice Extraction Process . . . . . . . . . . . . . . . . . . . . 113.1 The Extraction Task . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Analysis of the Task . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Navigating and Evaluating Dependencies . . . . . . . . . . . . . 13vi3.4 Actionable Extraction Decisions . . . . . . . . . . . . . . . . . . 153.4.1 Move to service (MS) . . . . . . . . . . . . . . . . . . . 163.4.2 Move to monolith (MM) . . . . . . . . . . . . . . . . . . 173.4.3 Confirm in service (CS) . . . . . . . . . . . . . . . . . . 183.4.4 Confirm in monolith (CM) . . . . . . . . . . . . . . . . . 183.4.5 Copy to service (C) . . . . . . . . . . . . . . . . . . . . . 183.5 Granularity of the Decisions . . . . . . . . . . . . . . . . . . . . 183.5.1 Source code . . . . . . . . . . . . . . . . . . . . . . . . . 183.5.2 Library code . . . . . . . . . . . . . . . . . . . . . . . . 193.5.3 Test code . . . . . . . . . . . . . . . . . . . . . . . . . . 204 The Extract Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . 214.1 Dependency Matrix . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Making Extraction Decisions . . . . . . . . . . . . . . . . . . . . 224.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.4 Heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.1 AcmeAir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.1.1 ET1: Booking Service . . . . . . . . . . . . . . . . . . . 275.1.2 ET2: Authentication Service . . . . . . . . . . . . . . . . 285.2 DayTrader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.2.1 ET3: Account Service . . . . . . . . . . . . . . . . . . . 295.2.2 ET4: Quote Service . . . . . . . . . . . . . . . . . . . . 295.3 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.5 ET1: Booking Service . . . . . . . . . . . . . . . . . . . . . . . 325.6 ET2: Authorization Service . . . . . . . . . . . . . . . . . . . . . 335.7 ET3: Account Service . . . . . . . . . . . . . . . . . . . . . . . . 355.8 ET4: Quote Service . . . . . . . . . . . . . . . . . . . . . . . . . 396 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.1 RQ1: Extraction Decision Drivers . . . . . . . . . . . . . . . . . 436.2 RQ2: Task Completion Indicators . . . . . . . . . . . . . . . . . 46vii6.3 RQ3: Extraction Decision Challenges . . . . . . . . . . . . . . . 486.3.1 Limited view of transitive dependencies . . . . . . . . . . 486.3.2 To copy, to move, or to confirm . . . . . . . . . . . . . . 486.3.3 Large number of interconnected elements . . . . . . . . . 496.3.4 Planning the next step in monolith decomposition . . . . . 506.4 RQ4: Tool-supported vs. Manual Designs . . . . . . . . . . . . . 506.4.1 Elements in tool-supported designs . . . . . . . . . . . . 516.4.2 Elements in manual designs . . . . . . . . . . . . . . . . 517 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558 Limitations and Future Work . . . . . . . . . . . . . . . . . . . . . . 569 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61viiiList of TablesTable 5.1 The order and type of decisions made in extracting the Bookingfeature as a service. . . . . . . . . . . . . . . . . . . . . . . . 35Table 5.2 The order and type of decisions made in extracting the Authorizationfeature as a service. . . . . . . . . . . . . . . . . . . . . . . . 37Table 5.3 The order and type of decisions made in extracting the Accountfeature as a service. . . . . . . . . . . . . . . . . . . . . . . . 39Table 5.4 The order and type of decisions made in extracting the Quotefeature as a service. . . . . . . . . . . . . . . . . . . . . . . . 42Table 6.1 Developer\u2019s rationale for performing extraction decisions. . . . 44Table 6.2 Extraction decisions and correctness of heuristic support. . . . 47Table 6.3 The elements present in Extract\u2019s designs of AcmeAir servicesand their presence in the manually extracted counterparts. . . . 53Table 6.4 The elements present in Extract\u2019s designs of DayTrader servicesand their presence in the manually extracted counterparts. . . . 54ixList of FiguresFigure 3.1 A model for an extraction process. Our approach specificallytargets the steps outlined by the dotted box. . . . . . . . . . . 14Figure 3.2 Movement to elements and dependencies in a move to servicedecision. Dependencies local to the monolith become cross-boundary, and cross-boundary dependencies become local tothe service. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Figure 3.3 Movement to elements and dependencies in a move to monolithdecision. Cross-boundary dependencies become local to themonolith and dependencies local to the service become cross-boundary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Figure 3.4 Movement to elements and dependencies in a copy decision.Cross-boundary dependencies become local to the service. De-pendencies from the copy to the monolith become cross-boundary,but dependencies of the original element from\/to the monolithremain local. . . . . . . . . . . . . . . . . . . . . . . . . . . 19Figure 4.1 A screenshot of the hierarchical dependency as presented tothe developer. . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figure 5.1 Initial Booking service seed and the resulting design afterextraction decisions . . . . . . . . . . . . . . . . . . . . . . . 34Figure 5.2 Initial Authorization service seed and the resulting de-sign after extraction decisions . . . . . . . . . . . . . . . . . 36xFigure 5.3 Initial Account service seed and the resulting design afterextraction decisions . . . . . . . . . . . . . . . . . . . . . . . 40Figure 5.4 Initial Quote service seed and the resulting design after ex-traction decisions . . . . . . . . . . . . . . . . . . . . . . . . 41Figure 6.1 Extraction decision versus rationale behind. . . . . . . . . . . 45xiAcknowledgmentsI am extremely grateful for the support and encouragement from Reid Holmesthroughout the duration of this work. After each meeting, I walked away withsomething new\u2014whether it was a fresh perspective on the work, an unexploredidea to experiment with, or a clear direction to focus my efforts.I could not have undertaken on this journey without the constant motivationand inspiration from my research companions, Marie Salomon and Katharine Kerr.Both of you consistently believed in my potential and offered invaluable guidanceduring moments of uncertainty. I am incredibly proud that, after numerous cof-fee walks, \u201canti-procrastination\u201d research meetings, and motivational brunches andhappy hours, we have all successfully reached the end of this journey together.I also want to express my gratitude to everyone in my life who has enrichedthe two years I spent in academia. To my parents, thank you for being my greatestchampions and for providing me with unwavering emotional and financial support.To Elisa, thank you for serving as my second reader and for showing me how tobecome a more effective TA through your remarkable patience with students. Tothe members of the SPL, I appreciate all of you for creating a fun and comfortablespace to work and socialize in. To my friends from high school and undergradu-ate years, thank you for giving me much-needed breaks from research while alsohelping me stay on track by constantly asking about my progress. It feels good tofinally be able to say \u201cI am graduating.\u201dLastly, I want to extend a special thanks to my cat, Mochi, for accompanyingme everyday through this journey. Mochi made a unique contribution to my workby occasionally taking a stroll across my keyboard.xiiChapter 1IntroductionMicroservice-based architectures have emerged as a popular architectural style formodernizing systems for increased scalabiltiy, flexibility, and productivity [10].Contrary to conventional monolithic applications, microservices architectures breakdown applications into distinct independently deployable \u201cmicroservices\u201d, whichcoordinate with each other over the network. The modular nature of microser-vices offers numerous benefits to modern industrial systems. Notably, it enablesthe system to adapt to changing capacity requirements by scaling up or down spe-cific parts of a system by deploying or removing the services [25]. Companies likeNetflix [21], Uber [13], and SoundCloud [3] have released engineering reports de-scribing the benefits of adopting the microservices architecture for their systems.However, despite the benefits, most systems do not initially adopt a fully-fledgedmicroservices approach. Rather, microservices architecture tend to be the outcomeof a long-term transition of an existing monolithic system [10].When introducing system-wide architectural changes, developers face two op-tions: to rewrite or to refactor. It is often tempting, in the face of technical debt,to start afresh by rewriting the legacy system. Yet, numerous industry case studieshave shed light on the risks in such big bang rewrites \u2014a complete overhaul ofa legacy system (e.g., [34, 39, 40]). In contrast to architectural changes throughrewriting, refactoring is the process of evolving an existing system from its cur-rent state to an improved state [23]. One specific refactoring pattern, coined the\u201cStrangler Fig\u201d by Martin Fowler, describes a method to gradually refactor legacy1monolithic systems by systematically replacing their components with microser-vices until the entire monolith is replaced [9]. The replacement proceeds iteratively,extracting features into new services, until the old monolith is \u201cstrangled\u201d and ismade obsolete by the extracted microservices. Contrary to a big-bang rewrite of amonolith into microservices, incremental replacement is significantly less intrusiveto the live monolith [31]. SoundCloud has employed the iterative pattern in theirmicroservices migration, where the legacy monolith and extracted microservicescoexisted throughout the migration, communicating with each other [3].There exist many previous research efforts to create tools for decomposingmonoliths, but these tools tend to perform the decomposition in a single step (e.g.,[7, 17, 19, 22, 24, 36, 41]). First, the tools perform static analysis to understandthe interactions between existing code components. Next, heuristics are used to tryto identify semantically-cohesive components that would be amenable to extrac-tion. Finally, the tools automatically extract these components into new microser-vices [35]. While these tools are useful for advising microservice candidates, theyessentially carry out sweeping large-scale changes in a single iteration, a risky ac-tion that developers try to avoid [25]. Consequently, the current tools do not alignadequately with developers\u2019 preferred decomposition workflows, as they prefer it-eratively examining services one by one [42].The thesis of this work is to propose an alternative approach that addresses it-erative decomposition for developers, focusing on a bottom-up strategy to enhancethe decomposition process. We implement this approach as a web-based proto-type called Extract. Extract helps developers identify and extract a specific featurefrom a monolithic Java application into a single microservice. To begin, the devel-oper makes an initial selection of elements (i.e., methods and classes) contained intheir monolith that they would like to extract into a service. Extract then staticallyconstructs a call graph relevant to the selected code to help the developer reasonabout what the dependencies are between the selected elements and the rest of thesystem. The call graph is visually presented with supplementary summary andease-of-extraction heuristics. Informed by the summary and heuristics, the devel-oper makes one of three \u201cextraction decisions\u201d for each of the methods and classesrelevant to the extracted service. Extraction decisions represent a developer\u2019s in-tention for a software element during the extraction process and directly translate2into corresponding actions. Extract dynamically updates the visualization as thedeveloper incrementally refines their decisions, until a desired microservice designis achieved.We evaluate the prototype with four case studies using open-source monolithicapplications and demonstrate how Extract can guide developers through makingactionable extraction decisions. Additionally, we compare the resulting designswith corresponding services from manual decomposition. We aim to determine theefficacy and shortcomings of our approach in producing designs that are compara-ble to manually derived ones.This thesis makes the following contributions:1. A bottom-up, iterative approach to monolith decomposition, accompaniedby a prototype tool implementation, called Extract, that applies this ap-proach.2. Four case studies using the prototype that demonstrates its capability in de-riving actionable extraction decisions.3. A report on the comparison tool-supported microservice designs to manuallyderived correspondence.3Chapter 2Related WorkAlthough research in bottom-up, iterative microservice extraction is scarce, theintent and mechanism of our approach overlaps with many existing research efforts.We detail the prior research here, along with the set of design goals we derived byleveraging and extending on prior research.2.1 Automated Monolith DecompositionSeveral projects have examined automating the decomposition of a legacy mono-lith into a set of microservices (e.g., [7, 17, 19, 22, 24, 36, 41]). Ponce et al.performed a review on the different decomposition techniques that have been pro-posed in the literature and identified three broad categories: model-driven, staticanalysis-based, and dynamic analysis-based [29]. Model-driven approaches usedesign elements like domain entities and data flow diagrams as input, which hasthe benefit of being technology-agnostic, but important elements like system per-formance tend to be neglected. Static analysis-based techniques use source code asinput which simplifies the identification of code dependencies, although they areoften language specific and may encounter challenges due to the lack of domainknowledge. Finally, dynamic analysis-based techniques offer the advantage of in-corporating runtime behaviors of live monolithic systems, but as with any otherdynamic analysis-based tools, the information they capture is incomplete, limitedto only those exercised during the analysis. Among the reviewed approaches, static4analysis-based techniques were predominant, comprising 45% of the total. Theseapproaches encompassed various forms of source code analysis, including hybridmethods that integrated static analysis with other techniques. Most static analysis-based approaches built a graph from the source code input, to which they applieda clustering approach. We focus on two decomposition tools which capture theessence of each category of monolith decomposition.Mazlami et al. proposed a semi-automated, formal approach for extracting mi-croservices candidates from monolithic systems [22]. They investigated two dif-ferent approaches for identifying semantically coupled classes within source code.The first approach utilized static analysis to graph the syntactic similarity betweenclasses, to which they applied Kruskal\u2019s Minimum Spanning Tree (MST) algo-rithm to cluster the classes into distinct microservices. In the second approach, amodel-driven method was employed, where co-change information was gatheredfrom the commit history of the monolith. They then clustered classes by catego-rizing classes modified together as highly similar. Of these two approaches, staticanalysis-based approach proved to be the most performant, based on their qualitymetrics of team size reduction and average domain redundancy. However, the au-thors acknowledge as a limitation in their approaches that the lowest computationalunit is a class. Using functions or methods as the finest level of granularity couldimprove the precision of the extraction task.Nakazawa et al. later performed a reproductive study of [22] and identified thatthe resulting microservices generated a large amount of inter-service communica-tion because MST clustering algorithm did not consider the degree of dependenciesbetween the clusters [24]. Hence, they proposed an alternative strategy to identifysimilar classes using dynamic analysis, which involved generating calling-contexttrees (CCTs) for the methods profiled in a sample run of the application. The CCT-based clustering produced microservices that communicated less frequently, butthe individual service sizes tended to be larger.We propose an approach that uses static analysis similar to Mezlami et al [22],but focuses on a single microservice extraction rather than whole-system decom-position. The resulting microservice design also takes into account the frequencyof inter-service communication, as the tool provides developers with dependencyinformation gathered through static call chain analysis. This enables them to eval-5uate the tradeoff between service size and runtime performance when devising aservice design.Design Goals IDG0 Encourage iterative extraction by targeting one service at a time.DG1 Provide support to evaluate the tradeoff of service size versus com-munication frequency.2.2 Feature-Oriented Dependency AnalysisThe idea of isolating a particular component from an existing system extends be-yond microservices and monolith decomposition. Dependency analysis of sourcecode elements is a common task supported by many tools that assist in defining afeature boundary in code (e.g., [32],[16],[5],[33],[6]).Robillard and Murphy introduced the \u201cconcern\u201d abstraction, where a concernis any conceptual unit of source code, such as a software feature [32]. The authorsimplemented the Feature Exploration and Analysis tool (FEAT) to represent sourcecode as a concern graph, and enabled developers to reason about concern-level de-pendencies. FEAT enabled developers to manage scattered concerns by leveragingmethods, fields, and types as the fundamental units of computation. Similar toFEAT, Extract allows developers to define a feature at the granularity of individualmethods, and to explore how the feature intended for extraction interacts with therest of the monolith. However, unlike FEAT which is designed primarily for broadprogram comprehension tasks, Extract offers heuristic advice to enable developersto make actionable decisions specific to their microservice extraction tasks.Holmes and Walker constructed Gilligan to help developers perform program-matic reuse tasks [16]. These tasks were defined as the pragmatic reuse of softwarefeatures from one system within a new system. The tool supports developers intracing static code dependencies to determine how much of the system would needto be reused to isolate the desired feature. Gilligan then automatically extracts theidentified feature for integration into the target system. Extract draws inspirationfrom Gilligan\u2019s approach by identifying feature boundaries via source code depen-6dency analysis and documenting the developer\u2019s decisions within the context oftheir task. But Gilligan itself would be limiting for the task of monolith decom-position as the approach is tailored for code reuse. For example, Gilligan onlyreasons about outgoing dependencies in its views, omitting incoming dependen-cies, to emphasize how the reused code relies on the system. We adapt and expandthe Gilligan\u2019s approach for monolith decomposition by taking into account bidi-rectional dependencies and introducing decisions specific to decomposition tasks.Design Goals IIDG2 Provide flexibility for defining a feature by allowing to make deci-sions at method granularity.DG3 Support analysis of both incoming and outgoing dependencies to rea-son about how the extracted feature is used by the remaining monolithand vice versa.2.3 Support for Decision MakingWhile the concept of fully-automated microservice extraction may seem appealing,there are arguments against tools replacing the decision-making role traditionallyperformed by developers [4]. Instead, tools should aid and enhance the decision-making processes of the people who build and maintain software systems.Automation has been widely applied to the field of test case generation, al-leviating developers of the need for manually creating test cases in the hopes ofidentifying software bugs (e.g., [2],[30],[37]). Developers instead apply tools toautomatically generate thousands of test cases for them. However, the generatedtest cases often lack readability, hindering developers from understanding the spe-cific aspects being tested [11]. Recognizing this challenge, Brandt and Zaidmanproposes a developer-centric test exploration tool that allow developers to studygenerated tests and decide whether to incorporate them into manually written testsuite [1]. For each test case, the tool presents the applied mutation and the cor-responding change in instructional coverage. With these information, developersmake informed decisions to either add or ignore any given generated test case.7Gilligan incorporates decision-making support in its tool suite for pragmaticreuse [16]. For each software structural element, Gilligan supports six \u201ctriage de-cisions\u201d that capture the developer\u2019s intent of reuse. For example, by tagging anelement as \u201cAccept\u201d or \u201cReject\u201d, the developer can specify that the element shouldor should not be reused. Already-made decisions are visually recorded within thetool, providing developers with clear feedback on the progress of their reuse task.Similarly, Gilligan lists any errors and remaining elements awaiting triage, provid-ing an overview of the remaining work.The decision-making support tools exhibit common features that make themuseful for developers. Drawing inspiration from these, we derive the followingadditional design goals to facilitate developers in making informed decisions aboutmicroservice extraction.Design Goals IIIDG4 Enable developers to make concrete, actionable decisions by offeringa well-defined set of task-specific questions.DG5 Make evident the consequences of each decision made by providinga visual overview of task progress and obstacles remaining to be con-sidered.2.4 Visualizing Structural DependenciesAs systems scale, the dependencies within them become increasingly intricate, pos-ing a significant challenge for visualizations [28]. Attempting to visualize suchcomplexity naively could result in information overload [15].Graph-based visualizations are the most predominant method for representingsoftware systems [38]. Its advantage lies in the ability to directly map softwareelements and relationships to a visual representation. Despite their intuitiveness,graphs often lack clarity, particularly when visualizing larger, more interconnectedsystems. One way to reduce cognitive load in large graphs is to enforce a hierar-chical ordering of the nodes. Holmes et al. utilize a tree-based dependency viewin Gilligan to structure the nodes based on containment, i.e., by organizing them8according to packages and classes [16]. Falke et al. present an alternative hierar-chical organization, involving dominance analysis, where at each level all childrenof a dominator are merged into the dominator [8].Metaphor-based visualizations offers an alternative approach that representssoftware elements as recognizable real-life objects, such as buildings and roads [38].For example, SArF map adopts the city metaphor, where each class is depicted asa building, each software feature as a block, and the relations between classesand features as the streets connecting them [18]. ExploreViz uses a similar citymetaphor to visualize the runtime behaviour of microservices and the interac-tions between them [19]. By associating software elements with familiar physicalstructures, a dependency graph can become more intuitive. This is advantageousfor general program comprehension and exploration tasks; however, metaphor-based visualizations are less popular for tasks involving architectural analysis anddecision-making [38]. Fitting the entire system in such metaphor suffers from thesame drawback as a naive graph-based visualization: information overload.Software dependencies can also be visualized using a matrix, for example intabular form [38]. Software elements are arranged in rows and columns, with cellsdenoting the relationship between the intersecting elements. Matrix-based visu-alizations are especially suitable for presenting dense dependency graphs or pre-senting supplementary information alongside the dependencies [12]. Laval et al.enhanced the cells of dependency matrices by incorporating information about thetype and proportion of dependence [20]. Through case studies, developers foundthe enriched dependency matrix useful for identifying and understanding circulardependencies within a system. However, the study also revealed that some de-velopers found such matrix representation less intuitive compared to alternativemethods such as those based on graphs.Considering both conciseness and intuitiveness, Extract incorporates both tree-based and matrix-based visualization in its dependency view. Similar to [20], itleverages the conciseness of a matrix to display summary and heuristic for eachdependency. Furthermore, instead of having single-level column and row headers,rows and columns uses trees to hierarchically arrange the software elements basedon package, class, and method containment.9Design Goals IVDG6 Concisely represent the dependencies and their associated summaryand heuristic information.DG7 Provide intuitive navigation of software elements by hierarchicallyarranging them based on package, class, method containment.10Chapter 3Microservice Extraction ProcessIn addition to the design goals derived from related work, we analyze a manualmicroservice extraction task to define a model for the extraction process. Givenits recurrent appearance in case studies within multiple research literature (e.g.,[14, 17]), we consider AcmeAir1 for this manual extraction task. AcmeAir is amonolithic Java application for airline management, and we extract its bookingfeature as a new Booking microservice. The manual extraction simulates de-veloper\u2019s approach to a single service extraction task, illustrating the necessaryinformation for identify and extract a functionally cohesive set of code.3.1 The Extraction TaskTo extract BookingService, the developer needs to initially pinpoint relevantfunctionality in the source code. The AcmeAir codebase follows a layered three-tier architecture with a top-level REST API tier, mid-level business logic tier, andbottom database tier. By inspecting the classes in the project view, the developeridentifies a group of classes potentially relevant to the booking feature, and realizesthat this feature spans across multiple tiers of the application.To carve out the feature, she begins by examining the entry point class, BookingsREST,and proceeds to explore its associated dependencies for other relevant classes. Itbecomes evident that BookingsREST delegates its tasks to the BookingService1https:\/\/github.com\/blueperf\/acmeair-monolithic-java11interface, which, in turn, is implemented by the BookingServiceImpl class.Since BookingService solely depends on its implementer, the developer theninvestigates the dependencies of BookingServiceImpl. BookingServiceImplis a database-tier class, responsible for initiating and managing communicationwith the underlying MongoDB database required for executing each operation pro-vided by BookingsREST. To carry out its tasks, it relies on several pieces: theConnectionManager class for accessing the \u201dbooking\u201d database, the KeyGeneratorfor creating unique IDs for new bookings, and an external serialization librarycalled org.bson.Unlike the previous classes, where determining their inclusion in BookingServicewas relatively straightforward, the developer requires additional analysis to decidethe appropriate course of action for ConnectionManager, KeyGenerator,and org.bson. Now, she needs to trace back the incoming dependencies ofthese classes, i.e. which other classes in AcmeAir rely on them. Upon investi-gation, she realizes that numerous other features in AcmeAir also make use ofthe methods provided by these classes. Removing them entirely from the ap-plication would result in breaking many such dependencies, and result to manyinter-service REST API calls. Instead, the developer opts to incorporate the de-pendencies into BookingService by duplicating ConnectionManager andKeyGenerator classes, and adding an external library dependency for org.bson.The developer justifies this approach as reasonable, as each of the duplicated classesis self-contained and does not introduce extensive dependencies of its own. Fur-thermore, each of these self-contained set of code is a common library shared bymultiple features of the system: a candidate for subsequent extraction.Finally, the developer aims to identify the incoming dependencies of all theexisting classes within BookingService. This analysis is crucial for determin-ing which methods should be exposed as external APIs for the remaining AcmeAirmonolith. By meticulously tracing the incoming dependencies of all 19 methods,she identifies that BookingService.dropBookings and BookingService.-getServiceType receive calls from the monolith. Based on this, the developerconcludes that she must externally expose the two aforementioned methods as partof BookingService\u2019s API and convert method calls to them into microserviceAPI calls.123.2 Analysis of the TaskFrom the manual extraction task, we derive a model of the extraction process towhich we base our approach:1. The developer identifies an initial set of classes and methods that could berelevant to the extracted feature.2. For each of the classes\/methods within the initial extraction candidate, thedeveloper follows its outgoing dependencies to determine the extent of ex-traction. For each software element it depends on, the developer decideswhether to include, exclude, or duplicate the element in the new service.Throughout this process, the initial service design undergoes iterative up-dates as necessary.3. The developer investigates each of the classes\/methods in the updated servicedesign (see 2), determining its incoming dependencies (i.e., what elementsin the monolith use the class\/method). By reviewing each dependency, thedeveloper makes a decision whether to retain the current service design oreliminate the class\/method from the service.4. The developer iterates on steps 2 and 3 until a satisfactory result is achieved,considering the level of dependencies between the monolith and the service.In the rest of this thesis, we refer to these dependencies as cross-boundarydependencies.5. Upon reaching a satisfactory service design, the developer evaluates eachcross-boundary dependency and identifies which elements require refactor-ing to operate across the network.6. The developer carries out the identified refactoring, thereby executing theservice extraction.3.3 Navigating and Evaluating DependenciesThe developer requires knowledge of both outgoing and incoming dependenciesin order to accurately make decision regarding inclusion or exclusion of a soft-13StartMake initial service designIdentify outgoingdependenciesIdentify incomingdependenciesEvaluatedependenciesUpdate servicedesignEvaluate designIdentify changeDonePerform changeTarget of ExtractFigure 3.1: A model for an extraction process. Our approach specifically tar-gets the steps outlined by the dotted box.14ware element from the microservice design. Together, the outgoing and incomingdependencies reflect the degree of coupling the element exhibit towards the mono-lith and the service. For example, elements having high number of incoming andoutgoing dependencies to the monolith are tightly coupled to the monolith, andthus should be excluded from the microservice. Additionally, each identified de-pendency needs to be classified as either local or crossing the extraction boundary.Local dependencies exist within the bounds of the monolith or the service, whereascross-boundary dependencies exist in-between the monolith and the service. Thedeveloper\u2019s primary objective is to minimize cross-boundary dependencies thatlead to unnecessary over-the-network calls and to maximize local dependenciesthat increase cohesion.A dependency of particular interest is the circular dependency, where two ormore software elements must directly or indirectly depend on each other to func-tion properly. In the context of microservices, a circular dependency is a cyclicchain of calls among microservices (e.g., Service A calls Service B, B calls C, andC calls back to A). This kind of dependency is considered an anti-pattern for mi-croservices, as it hinders the independent evolution of participating services [27].Although circular dependencies between services are typically undesirable in a fi-nalized microservices architecture, they might be intentionally introduced duringan iterative extraction process. Thus, another goal when devising an extractiondesign is to avoid unnecessary circular dependencies (rather than completely elim-inate them) between the extracted service and the remaining monolith.3.4 Actionable Extraction DecisionsBased on the nature of dependencies identified, the developer must make decisionfor each involved software elements that align with the two extraction goals men-tioned earlier. We establish five actionable extraction decisions that represent thedeveloper\u2019s intentions for a software element during the extraction process. Eachdecision focuses on one software element at a time, making the extraction designspecific and, as a result, \u201cactionable\u201d.15Element AElement BElement Clocal localcrosscrossMonolith ServiceElement EElement DcrosscrossMonolithElement BElement CServiceElement EElement DElement AlocallocalMove to ServiceFigure 3.2: Movement to elements and dependencies in a move to servicedecision. Dependencies local to the monolith become cross-boundary,and cross-boundary dependencies become local to the service.3.4.1 Move to service (MS)The software element exists in the monolith in the service design, and the developerdetermines that it should be part of the extracted service instead. By moving theelement to the service, all dependencies from\/to the service become local, while alldependencies from\/to the monolith become cross-boundary. (See Figure 3.2)16Element AElement BElement Clocal localcrosscrossMonolith ServiceElement EElement DcrosscrossMonolithElement BElement CServiceElement EElement DElement AlocallocalMove to MonolithFigure 3.3: Movement to elements and dependencies in a move to monolithdecision. Cross-boundary dependencies become local to the monolithand dependencies local to the service become cross-boundary.3.4.2 Move to monolith (MM)The element exists in the service in the current service design, and the developerdecides that it should be part of the monolith instead. By moving the element tothe monolith, all dependencies from\/to the monolith become local, and all depen-dencies from\/to the service become cross-boundary. (See Figure 3.3)173.4.3 Confirm in service (CS)Confirm in service decision represents that the developer is confident that an el-ement currently in the service should indeed remain in the service, based on theanalyzed dependencies. This decision does not result in any alterations to the ser-vice design or its dependencies.3.4.4 Confirm in monolith (CM)If the developer concludes that there is substantial evidence supporting the inclu-sion of an element in the monolith, then the element is tagged as confirmed inmonolith.3.4.5 Copy to service (C)Copy to service decision is used when an element currently resides in the monolith,and the developer decides to replicate the element for utilization in the service.By copying the element, any dependencies to\/from the service become local to theservice, while dependencies from the copy to the monolith become cross-boundary.Note that unlike a move decision, dependencies from the monolith remain localsince the element is not removed from the monolith. (See Figure 3.4)3.5 Granularity of the DecisionsThe developer requires making decisions at different levels of granularity depend-ing on the software element at hand. We identify three types of software code:3.5.1 Source codeIn most extraction tasks, the main target of analysis is the source code, where thedeveloper aims to isolate a specific feature from the codebase. Source code canbe organized in different ways, such as by packages, by features, by layers, or byresponsibilities, and the chosen structure determines whether features are closelygrouped or scattered throughout the codebase [26]. This necessitates making de-cisions at different levels of granularity, including at package, class, method, andfield-level.18Element AElement BElement Clocal localcrosscrossMonolith ServiceElement EElement DCopy to ServiceElement AElement Blocal localMonolithElement CServiceElement EElement DElement AlocallocalcrossFigure 3.4: Movement to elements and dependencies in a copy decision.Cross-boundary dependencies become local to the service. Dependen-cies from the copy to the monolith become cross-boundary, but depen-dencies of the original element from\/to the monolith remain local.3.5.2 Library codeWhen the source code of interest relies on external libraries, the developer mustalso make decisions regarding the library code. Unlike source code decisions,where flexibility in granularity is essential, extraction decisions for libraries aremade as a whole. In other words, the service either depends on the library entirelyor does not depend on it at all.193.5.3 Test codeThe system may include test code to validate the feature being extracted. Whenextracting a feature, the developer aims to extract the relevant tests along with it.Typically, in Java systems, test code is organized to mirror the structure of the mainsource code, requiring a similar level of flexibility in decision granularity. This in-cludes decisions at test suite-level and test case-level.In our prototype, our primary focus is on source code and library code, and wedifferentiate between these two types of code by providing distinct levels of deci-sion granularity. As well, the granularity we choose methods to be the lowest levelof source code granularity (thereby excluding fields) to maintain simplicity of de-pendency analysis. We consider extensions to test code and field-level granularityas potential future work.20Chapter 4The Extract PrototypeWe describe here the components of the prototype and how they contribute to thedesign goals from Section 2. The prototype is developed as a Java application,featuring a user-facing React frontend. The Java backend takes as input a JARfile of the monolithic application, and generates a dependency graph of the soft-ware elements. In this version of the prototype, we rely exclusively on call graphinformation to generate the dependency graph. However, future iterations shouldexpand this analysis to encompass other types of dependencies including inheri-tance, implementation, parameter, and return dependencies.The React frontend interacts with the backend by requesting a partial depen-dency graph, based on the initial microservice design provided by the developer.We provide an overview of how the frontend visually presents this information andthe interactions it supports.4.1 Dependency MatrixThe user interface presents a matrix-based view of dependencies, where microser-vice elements are arranged in columns, and monolith elements in rows. order of el-ements in rows and columns follows a hierarchical structure based on package andclass containment (DG6, DG7). Source code elements are presented with methodlevel granularity, permitting for detailed analysis of what is contributing to the de-pendency. Non-source code elements from external libraries are also shown in the21matrix, but at the granularity of the entire library. This design choice treats librariesas black boxes and helps differentiate source code elements from non-source codeelements.To initiate the extraction task, the developer first selects a set of elements (pack-ages, classes, methods) that constitute the initial microservice seed. These servicemethods are presented in rows, while the columns display all elements that ei-ther depend on or are depended upon by the service methods. We refer to thecolumn elements as the monolith methods. The cells of the matrix contain de-pendency information for the intersecting service and monolith methods (Figure4.1-1). Specifically, they represent direct outgoing, direct incoming, transitive out-going, and transitive incoming dependencies (DG2).4.2 Making Extraction DecisionsExtract offers decision-making capabilities at different levels of granularity, includ-ing method-level decisions (DG1, DG4). This provides the developer flexibility incustomizing the scope of decisions, allowing for precise specification of the result-ing service. Each column element supports move to service, confirm in monolith,and copy to service decisions, while each row element supports move to monolithand confirm in service decisions (Figure 4.1-5). These decisions correspond to theactionable extraction decisions introduced in Section 3. Once a decision is made,the element is marked for visual feedback and the dependency matrix updated ac-cordingly. This ensures that the developer can track and visualize the impact oftheir decisions on the matrix (DG5).4.3 SummaryFor each row and column, we display summarized dependency information: thecolumn summary (Figure 4.1-2), and the row summary (Figure 4.1-3). A summarycell comprises four values, representing aggregate counts of dependencies in thefollowing categories:1. Dependencies from other service elements to the element.2. Dependencies from monolith elements to the element.223. Dependencies from the element to other service elements.4. Dependencies from the element to monolith elements.The summary information provides a quick overview of the degree of couplingan element exhibits between the service and the monolith. Upon hovering any ofthe summary values, a popup appears, showing the specific elements contributingto the value (Figure 4.1-4).4.4 HeuristicsThe prototype supports five heuristics designed to inform developers in makingextraction decisions effectively. The goal of the heuristics is to simplify the identi-fication of elements that the developer should focus on next in the extraction task.They can pinpoint elements that are potentially misplaced in the service design(DG5).In general, elements that are well-suited for inclusion in the service are high-lighted in green, while elements that are more likely to belong to the monolithare marked in red. These visual cues aid developers in discerning the potentialplacement of each element, facilitating the decision-making process.The five heuristics supported are:H1: Move to service:If a monolith element only depends on service, it likely belongs in the serviceinstead.H2: Move to monolith:If a service element only depends on monolith, it likely belongs in the mono-lith instead.H3: Confirm in service:If a service element only depends on the service, it likely does belong in theservice.H4: Copy to service:If an element is similarly coupled to both service and monolith, then it likely23belongs in both.FromService+ToServiceTotal\u2248\u03b1 FromMono+ToMonoTotal (4.1)where \u03b1 is the threshold valueH5: Confirm in monolith:If an element has higher coupling to monolith than service, it likely belongsin the monolith.FromService+ToServiceTotal<<\u03b1FromMono+ToMonoTotal(4.2)where \u03b1 is the threshold valueH1-H3 are all straightforward and definitive heuristics used to determine theinclusion and exclusion of elements. If methodA within the monolith relies onelements dep1, dep2, and dep3, all of which are already included in the service,H1 highlights methodA green. Likewise, if methodA was a service element, H3would mark it in green to confirm its inclusion within the service. On the otherhand, if methodA existed in the service, and its dependencies dep1, dep2, anddep3 were monolith elements, H2 would highlight methodA in red.H4 and H5 are both heuristics relative to the chosen threshold value. Thus,their accuracy vary depending on the \u03b1 value and the target monolithic system.To identify copy candidates, H4 evaluates the proportions of service dependenciesto the overall number of dependencies, as well as monolith dependencies to thetotal count. When the difference in ratios falls within the defined threshold \u03b1 ,H4 classifies the element as possessing comparable coupling with both the serviceand the monolith. A higher value of \u03b1 would render this heuristic more lenient(identifying more elements for copying), while a lower \u03b1 would make it stricter.H5 operates in a similar manner by contrasting the identical ratios, but looks forelements that have significantly different values (i.e., more than \u03b1) as confirm inmonolith candidates. Having a higher \u03b1 value makes the heuristic stricter (per-mitting only elements with significantly more monolith dependencies than servicedependencies), while a lower value makes it more lenient.2423145Service Elements Monolith ElementsFigure 4.1: A screenshot of the hierarchical dependency as presented to thedeveloper.25Chapter 5Case StudiesWe performed a total of four case studies to illustrate how the prototype is used todecompose Java monolithic systems. Each case study involves a service extractiontask where a particular feature, characterized by the developer-input initial servicedesign, is extracted from the monolith. We describe each monolith used and ex-traction task of the case studies below. For our case studies, we excluded the testcode from our task, focusing only on the source code.The aim of the case studies is two-fold. First, they serve as illustrative sce-narios of using the Extract prototype against sample monolithic system. Second,through the case studies we investigate the following research questions regardingthe prototype and microservice extraction tasks.Research QuestionsRQ1 What are the drivers for each extraction decision? Do the heuristicssupport the decision made?RQ2 What is the criteria or indicators that signal the completion of an ex-traction task?RQ3 What factors impact the difficulty in making an extraction decision?RQ4 How do the tool-supported microservice designs compare to manu-ally performed designs?265.1 AcmeAirAcmeAir1 is a Java implementation of a fictitious airline management system withthe responsibilities to manage web API requests and communicate with the un-derlying MongoDB database. In the realm of monolith decomposition, AcmeAirstands out not only as a prominent candidate for evaluating decomposition toolsbut also as a representative instance of a conventional Java application organizedby features, making it an ideal choice for our case study. AcmeAir consists of2,414 lines of source code (LOC), 30 classes, 3 interfaces, and 180 methods. Themonolith is organized in a 3-tier architecture with the REST API tier, businesslogic tier, and database management tier. Each tier is further subdivided for eachsupported business functionality: Authentication, Booking, Customermanagement, and Flight management. This means locating a feature requireslooking across the tiers, but within each tier, the pertinent code is typically colo-cated. In addition, there are utility code shared by each functionality for load-ing system configurations, initiating MongoDB connection, and serving the RESTAPIs. We perform two extraction tasks (ET) involving AcmeAir monolith. Werandomly select two features to be extracted in ET1 and ET2.5.1.1 ET1: Booking ServiceThe first task aims to extract all code involved in booking management as a singlemicroservice. To begin, the developer makes an initial booking service design byselecting classes and methods they consider to be part of the microservice. Fourclasses were pre-selected for this purpose.\u2022 com.acmeair.web.BookingREST\u2022 com.acmeair.service.BookingService\u2022 com.mongo.services.BookingServiceImpl\u2022 com.acmeair.loader.BookingLoader1https:\/\/github.com\/blueperf\/acmeair-monolithic-java275.1.2 ET2: Authentication ServiceThe second task, authentication service involves all code implementing the man-agement of user sessions. As with the Booking feature, four classes were pre-selected as initial service design.\u2022 com.acmeair.web.LoginREST\u2022 com.acmeair.service.AuthService\u2022 com.mongo.services.AuthServiceImpl\u2022 com.acmeair.loader.SessionLoader5.2 DayTraderDayTrader2 is an end-to-end benchmark and performance sample application asan online stock trading system, with the capability for users to login, view theirportfolio, lookup stock quotes, and buy and sell their shares. It is another exten-sively utilized Java monolithic application for assessing tools related to monolithdecomposition, and unlike AcmeAir which packaged source code elements by fea-tures, it demonstrates package-by-layer organization. We select DayTrader for ET3and 4 in these regards. The monolith is built on Java EE 7, using WebSockets forclient-server communication and JDBC for SQL database connection. We focuson the module daytrader-ee7-ejb for our case studies, where most appli-cation logic exist. The module consists of 6,550 LOC, 27 classes, 4 interfaces,and 493 methods. Compared to AcmeAir, the features of DayTrader are morecoupled within the source code. The entry-points to its functionality coexists inTradeService interface, implemented by TradeDirect, TradeSLSBRemoteand TradeSLSBLocal, which are three different modes supported by DayTrader.The three classes each provide implementations for the supported features includ-ing Quote retrieval, Account management, and Portfolio management. Weperform additional two extraction tasks involving DayTrader monolith. Followingearlier case studies, we randomly select two features from the available choices forET3 and 4.2https:\/\/github.com\/WASdev\/sample.daytrader7285.2.1 ET3: Account ServiceThe Account feature contains methods servicing user registration, login and lo-gout, and retrieving and updating account information. The following methodsfrom TradeService and its implementers were selected in the initial design.\u2022 TradeService, TradeAction, ejb3.TradeSLSBBean:\u2013 login\u2013 logout\u2013 register (2 overloaded methods for TradeAction)\u2013 getAccountData\u2013 getAccountProfileData\u2013 updateAccountProfile\u2022 direct.TradeDirect:\u2013 login\u2013 logout\u2013 register\u2013 getAccountData (4 overloaded methods)\u2013 getAccountProfileData (3 overloaded methods)\u2013 updateAccountProfile (2 overloaded methods)\u2013 getAccountDataFromResultSet\u2013 getAccountProfileDataFromResultSet5.2.2 ET4: Quote ServiceThe Quote feature implements functionalities for creating and retrieving stockquotes. The following methods were preselected in the initial QuoteServicedesign.\u2022 TradeService, TradeAction\u2013 getAllQuotes29\u2013 getQuote\u2013 createQuote\u2013 updateQuotePriceVolume\u2022 direct.TradeDirect\u2013 getAllQuotes\u2013 getQuote (2 overloaded methods)\u2013 createQuote\u2013 updateQuotePriceVolume (2 overloaded methods)\u2013 getQuoteData\u2013 getQuoteForUpdate\u2013 getQuoteDataFromResultSet\u2013 updateQuotePriceVolumeInt\u2013 publishQuotePriceChange\u2022 ejb3.TradeSLSBBean\u2013 getAllQuotes\u2013 getQuote\u2013 createQuote\u2013 updateQuotePriceVolume\u2013 publishQuotePriceChange5.3 ProcedureIn each case study, we documented the extraction decisions, including the chosensoftware element, the reasoning behind the decision, and the order in which thedecisions were made. For each software element involved in the decision, we alsorecorded the relevant lines of code. These lines of code provided a means to esti-mate the size of the resulting microservice design. Each task was undertaken by anauthor as the participant. Furthermore, we performed each extraction task twice,first without the heuristic support and then with heuristics. In the second attempt,30the participant replicated the same extraction while recording any heuristic in sup-port of the decisions. During the case study, a threshold of 0.5 was used for H4 and0.7 for H5. No time constraints were imposed to allow the participant to completeeach task fully. This ensured that we could confirm the end condition of an extrac-tion task (RQ3). Throughout the process, the participant had access to the sourcecode of each monolith.315.4 ResultsBelow we describe the results of the case studies. For illustrative purpose, wepresent a detailed overview of the decisions made and the reasoning behind themfor both ET1 and ET3. However, for the second case study involving each mono-lithic system (ET2, ET4), we present a concise summary of the results.5.5 ET1: Booking ServiceET1 involved a total of 8 extraction decisions, which comprised 4 copy, 3 moveto service, and 1 confirm in monolith decisions. Table 5.1 provides a summary ofeach decision made, the target of the decision, and lines of code involved in thedecision. Figure 5.1 illustrates the movement of elements and dependencies beforeand after the extraction decisions.From the initial service seed, the participant noticed a significant imbalance independencies, with 24 dependencies from the service to the monolith and only 5dependencies from the monolith to the service. To minimize the cross-boundarydependencies, the participant studied the row summaries and detail popups to iden-tify the major contributors to the high dependency from the service to the monolith.They found that calls to the external library org.bson.Document accountedfor 6 out of the 24 dependencies. Based on this information and the column sum-mary of the library, the participant decided to copy the org.bson library to theservice, as two other elements in the monolith also depended on it. A copy decisionwas also made for com.mongodb library based on a similar rationale.These decisions effectively reduced the dependencies from the service to themonolith to three \u20141\/8 of the initial design. The participant continued to re-duce the dependencies further, aiming to eliminate the circular dependency be-tween the monolith and the service. One of the remaining dependencies was acall to services.KeyGenerator.generate method in the monolith frommongo.services.BookingServiceImpl.bookFlight. By looking itscolumn summary, the participant decided to copy this method, as it was used byother elements in the monolith but did not have any dependencies back to the mono-lith. The participant also referred to the source code of the method to ensure thatcopying it did not transitively require copying all its dependencies. The remaining32two dependencies from the service to the monolith involved calls to methods in themongo.ConnectionManager class. Using the same reasoning, the participantdecided copy is an appropriate decision.With the outgoing dependencies to the monolith reduced to zero, the participantthen tried to minimize the incoming dependencies. It was found that the servicemethod loader.BookingLoader.dropBookings was being called fromtwo elements in the monolith: loader.Loader.execute and loader.Loader.-executeBookingDB. The participant decided to move executeBookingDBmethod to the service since its name suggested inclusion to the Booking service,and it only had one dependency from the monolith (ensuring the move decisionwould not increase cross-boundary dependency). However, the participant choseto confirm the execute method in the monolith, as it had higher coupling withthe rest of the monolith (2 incoming, 5 outgoing).Moving executeBookingDB caused a new monolith element, loader.-Loader.clearBookingDB to depend on the service. After confirming thatclearBookingDB had zero dependencies to the monolith, the participant made amove decision for this method as well. Similarly, the methods config.AcmeAir-Configuration.countBooking and config.AcmeAirConfiguration.-getActiveDataServiceInfo in the monolith called methods in service.-BookingService of the service, but had no dependency back to the monolith.Consequently, the participant applied the move to service decision for these meth-ods as well.In the resulting design of Booking service, the monolith depends on loader.-BookingLoader.dropBookings of the service, which the participant shouldsurface as service API. By considering the lines of code (LOCs) of all copied andmoved elements, we estimate that 61 additional lines of code were introduced,along with two libraries: org.bson (238KB) and com.mongodb (1.6MB) inJAR sizes, respectively.5.6 ET2: Authorization ServiceDuring ET2, the participant made a total of 11 extraction decisions, consisting of5 copy, 4 move to service, and 2 confirm in monolith decisions. Table 5.2 provides33Monolithorg.bson<KeyGenerator>generate<ConnectionManager><Loader>executeBookingDB<Loader>execute<Loader>clearBookingDB<AcmeAirConfiguration>com.mongodbService<BookingService><BookingREST><BookingLoader><BookingServiceImpl>Monolithorg.bson<KeyGenerator>generate<ConnectionManager><Loader>executecom.mongodbService<BookingService> <BookingREST><BookingLoader><BookingServiceImpl>com.mongodborg.bson<KeyGenerator>generate<ConnectionManager><Loader>executeBookingDB<Loader>clearBookingDB<AcmeAirConfiguration>Library elementSource elementSeed service elementMoved elementConfirmed elementCopied elementCross-boundarydependenciesLocal dependenciesFigure 5.1: Initial Booking service seed and the resulting design after ex-traction decisions34# Decision Element Type Element LOC1 C Library org.bson \u20142 C Library com.mongodb \u20143 C Method com.acmeair.services.KeyGenerator.generate 34 C Class com.acmeair.mongo.ConnectionManager.* 135 MS Method com.acmeair.loader.Loader.executeBookingDB 166 CM Method com.acmeair.loader.Loader.execute 97 MS Method com.acmeair.loader.Loader.clearBookingDB 38 MS Class com.acmeair.config.AcmeAirConfiguration.* 26Table 5.1: The order and type of decisions made in extracting the Bookingfeature as a service.a summary of the order, target element, and size (LOC) of each decision made.Figure 5.2 illustrates the movement of elements and dependencies before and afterthe extraction decisions.As in ET1, the participant completed the task once decisions were made for allmonolith (column) elements. In the resulting service design, the participant suc-cessfully reduced cross-boundary dependencies to 2, but a circular dependency re-mained. The monolith called to loader.SessionLoader.dropSessionsin the service, while the service called to service.CustomerService.-validateCustomer in the monolith. The participant deemed this circular de-pendency acceptable since the monolith was in an intermediary stage of full decom-position. The participant expected that the Customer feature would be of interestfor future extraction, and eventually, the dependency from the Authorizationservice could be redirected to the Customer service.The change in service size from the initial service seed was an additional 95LOC, 23KB from org.json library, 238KB from org.bson, and 1.6MB fromcom.mongodb.5.7 ET3: Account ServiceCompared to ET1 and ET2 where the initial service design comprised coarse-grained class elements, the services extracted from DayTrader in ET3 exhibitedmethod-level granularity. This finer granularity was a consequence of the highinterdependence among features in the system, necessitating a greater need for35Monolithorg.bson<KeyGenerator>generate<ConnectionManager><Loader>executeSessionDB<Loader>execute<Loader>clearSessionDB<AcmeAirConfiguration>com.mongodborg.json<CustomerService>validateCustomer<RESTCookiesSessionFilter>doFilterService<SessionLoader><AuthService><LoginREST><AuthServiceImpl>Monolithorg.bson<KeyGenerator>generate<ConnectionManager><Loader>executecom.mongodborg.json<CustomerService>validateCustomerService<AuthService> <LoginREST><SessionLoader><AuthServiceImpl>com.mongodborg.bson<KeyGenerator>generate<ConnectionManager><Loader>executeSessionDB<Loader>clearSessionDB org.json<RESTCookiesSessionFilter>doFilter<AcmeAirConfiguration>Library elementSource elementSeed service elementMoved elementConfirmed elementCopied elementCross-boundarydependenciesLocal dependenciesFigure 5.2: Initial Authorization service seed and the resulting designafter extraction decisions36# Decision Element Type Element LOC1 C Library org.bson \u20142 C Library org.json \u20143 C Library com.mongodb \u20144 C Method com.acmeair.services.KeyGenerator.generate 35 C Class com.acmeair.mongo.ConnectionManager.* 136 MS Method com.acmeair.web.RESTCookiesSessionFilter.doFilter 457 MS Method com.acmeair.loader.Loader.executeSessionDB 168 MS Method com.acmeair.loader.Loader.clearSessionDB 59 CM Method com.acmeair.loader.Loader.execute 910 MS Method com.acmeair.config.AcmeAirConfiguration.- 13countCustomerSession11 CM Method com.acmeair.services.CustomerService.- 13validateCustomerTable 5.2: The order and type of decisions made in extracting theAuthorization feature as a service.flexibility when defining its service design.The participant executed a total of 10 extraction decisions, comprising 2 con-firm in service, 7 copy, and 1 confirm in monolith decisions. Table 5.3 summarizesthe result of ET3. Figure 5.3 illustrates the movement of elements and dependen-cies before and after the extraction decisions.Due to the large number of seed elements in the service, the participant hadto expand and delve into the rows to analyze the individual contributions of eachpackage and class. The participant first noted that the class TradeServices inthe service only had dependencies within the service itself, leading to a confirm inservice decision.Next, the participant observed from the row summaries a substantial number ofoutgoing dependencies from TradeActions.* and direct.TradeDirect.*methods to util.Log.* in the monolith. After confirming that the dependen-cies of these methods were self-contained within the Log class and served purelyfor event recording functions, the participant decided to copy the Log class tothe service. Row summary and source code of Log class were used. Copying theLog class also eliminated all the outgoing dependencies from TradeActions.*methods to the monolith, leading the participant to make a confirm in service deci-sion for TradeActions.*.On the other hand, direct.TradeDirect.* still had remaining outgoingdependencies to the monolith. To minimize this dependency, the participant iden-37tified a set of database connection and transaction utility methods as candidates foradditional Copy decisions. The methods, such as direct.TradeDirect.commit,getConn, releaseConn, rollBack, getInGlobalTxn, getStatement,and getDataSource, did not have trailing transitive dependencies, making themsuitable for copying. The participant avoided moving these methods as many otherelements in the monolith depended upon them, as indicated by the correspondingcolumn summary. Copying the methods of direct.TradeDirect.* led tonew outgoing dependencies from the service to additional logging methods, whichthe participant also decided copy. This decision reduced the outgoing dependenciesfrom service to the monolith to from 116 to 30.The participant examined the top-level row summary and found that the ma-jority of remaining dependencies were to entities.AccountDataProfileand entities.AccountData classes. She concluded that they were data typedefinitions that probably had practical use in both the service and the monolith.This lead to copy decisions being made for both classes.By applying the same analysis and reasoning, the participant also made acopy decision for KeySequenceDirect.getNextID method. But the de-cision introduced extra outgoing dependencies transitively, as the method calledKeyBlock$KeyBlockIterator.hasNext and next() in the monolith.After reviewing the source code and resolving getNextID\u2019s transitive depen-dencies, the participant deemed that copying all the transitive dependencies wouldbe acceptable since it would result in only a slight increase in LOC in the service.The two remaining outgoing dependencies both involved the util.TradeConfigclass. The logging methods copied (Decision 2) queried TradeConfig.getTraceand TradeConfig.getActionTrace, both return boolean values to config-ure the logs. Even though these two methods were simple to copy (i.e., they wereself-contained), the participant chose to confirm them in the monolith. Applyingthe alternative copy decisions would have removed the circular dependency be-tween the monolith and the service, but the participant reasoned that TradeConfigshould eventually be extracted as a service on its own for centralized configurationmanagement service.As a result, the resulting service design had three incoming dependencies fromthe monolith to the service and two outgoing dependencies. The service is used by38TradeDirect.buy, sell, and completeOrder, and the two methods theyutilize, TradeDirect.getAccountProfileData and getAccountData,need to be surfaced as Account service API. The increase in the size of servicefrom the initial design was 374 LOC.# Decision Element Type Element LOC1 CS Class TradeServices.* 62 C Class util.Log.* 423 CS Class TradeActions.* 524 C Method direct.TradeDirect.commit, getConn, releaseConn, 58rollBack, getInGlobalTxn, getStatement, getDataSource5 C Method util.Log.getTrace, getActionTrace, log 96 C Class entities.AccountProfileDataBean 1007 C Class entities.AccountDataBean 1648 C Method KeySequenceDirect.getNextID 169 C Method KeyBlock$KeyBlockIterator.hasNext, next 410 CM Method util.TradeConfig.getTrace, getActionTrace 6Table 5.3: The order and type of decisions made in extracting the Accountfeature as a service.5.8 ET4: Quote ServiceET4 involved a total of 10 extraction decisions, which included 4 copy, 3 move toservice, and 2 confirm in service decisions. Table 5.4 summarizes the result of thetask. Figure 5.4 illustrates the movement of elements and dependencies before andafter the extraction decisions.In general, the order and choice of decision were similar to those of Accountservice from ET3. However, unlike the confirm decisions made for util.Trade-Config.getTrace and getActionTrace in Decision 5 of ET3, the partic-ipant opted to make move to service decisions for two other configuration values:getUpdateQuotePrices and getPublishQuotePriceChange. In theformer case, the participant noticed from the column summary that the configura-tions were accessed by other elements of the monolith, while in the latter case, theywere exclusively utilized by the service.The overall increase in the size of the design before and after the task amountedto 230 LOC.39Monolith<util.Log><AccountProfileDataBean><AccountDataBean><KeySequenceDirect>getNextID<KeyBlock$KeyBlockIterator>hasNext,next<TradeDirect>commit,getConn,releaseConn,etc<TradeConfig>getTrace,getActionTrace<TradeDirect>buy, sell,completeOrderService<TradeServices>.*<TradeAction>.*<TradeDirect>.*<TradeSLSBBean>.*Monolith<util.Log><AccountProfileDataBean><AccountDataBean><KeySequenceDirect>getNextID<KeyBlock$KeyBlockIterator>hasNext,next<TradeDirect>commit,getConn,releaseConn,etc<TradeConfig>getTrace,getActionTrace<TradeDirect>buy, sell,completeOrderService<TradeServices>.*<TradeAction>.*<TradeDirect>.*<TradeDirect>commit,getConn,releaseConn,etc<util.Log><AccountDataBean><AccountProfileDataBean><KeyBlock$KeyBlockIterator>hasNext,next<KeySequenceDirect>getNextID<TradeSLSBBean>.*Library elementSource elementMoved elementConfirmed elementCopied elementCross-boundarydependenciesLocal dependenciesFigure 5.3: Initial Account service seed and the resulting design after ex-traction decisions40Monolith<util.Log><QuoteDataBean><TradeSLSBBean>postConstruct<TradeSLSBLocal>publishQuote...<TradeDirect>commit,getConn,releaseConn,etc<TradeConfig>getTrace,getActionTrace<TradeDirect>getMarketSummary,buy, sell<TradeConfig>getUpdate...,getPublish...Service<TradeSLSBBean>.*<TradeServices>.*<TradeAction>.*<TradeDirect>.*Monolith<QuoteDataBean><util.Log><TradeConfig>getTrace,getActionTrace<TradeDirect>getMarketSummary,buy, sell<TradeDirect>commit,getConn,releaseConn,etcService<TradeServices>.*<TradeDirect>.*<TradeAction>.*<util.Log><QuoteDataBean><TradeConfig>getUpdate...,getPublish...<TradeSLSBLocal>publishQuote...<TradeSLSBBean>postConstruct<TradeDirect>commit,getConn,releaseConn,etc<TradeSLSBBean>.*Library elementSource elementMoved elementConfirmed elementCopied elementCross-boundarydependenciesLocal dependenciesFigure 5.4: Initial Quote service seed and the resulting design after extrac-tion decisions41# Decision Element Type Element LOC1 CS Class TradeServices.* 42 C Class util.Log.* 323 C Class QuoteDataBean 1174 MS Method util.TradeConfig.getUpdateQuotePrices, 6getPublishQuotePriceChange5 CM Method util.TradeConfig.getTrace, getActionTrace 66 MS Method ebj3.TradeSLSBLocal.publishQuotePriceChange 17 MS Method ebj3.TradeSLSBean.postConstruct 78 C Method direct.TradeDirect.commit, getConn, releaseConn, 58rollBack, getInGlobalTxn, getStatement, getDataSource9 C Method util.Log.getTrace, getActionTrace, log 910 CM Class TradeDirect.getMarketSummary 67Table 5.4: The order and type of decisions made in extracting the Quotefeature as a service.42Chapter 6DiscussionWe further analyze the result of case studies and discuss them in terms of ourresearch questions. Our main focus of analysis revolves around identifying factorsthat either facilitate or hinder decision-making during a microservice extractiontask. We focus less on the success or accuracy of the resulting service designfrom each extraction task, but perform a comparison against manually decomposedmicroservice designs of the respective monolith.6.1 RQ1: Extraction Decision DriversResearch Question I(a)What are the drivers for each extraction decision?Table 6.1 presents the participant\u2019s rationale behind each extraction decisionmade while performing the extraction tasks. The decisions are keyed by its tasknumber and order as given by Tables 5.1-5.4. For instance, the eighth decision inextraction task 3 is keyed as ET3-8. Figure 6.1 plots the proportion of rationalesbehind each extraction decision. The participant did not make a Move to servicedecision in the case studies and so we remove it from this analysis.As we observe from Figure 6.1, Copy decisions are primarily motivated by thetarget element having a similar degree of coupling to both the monolith and the ser-vice. On the other hand, Move to service decisions are made when the element in43Extraction DecisionRationaleInformation Used DecisionR1 A monolith element isdepended upon signifi-cantly by both the ser-vice and the monolithColumn summary ET1-1, ET1-2, ET1-3,ET1-4, ET2-1, ET2-2,ET2-3, ET2-4, ET2-5,ET3-2, ET3-4, ET3-5,ET3-6, ET3-7, ET3-8,ET3-9, ET4-2, ET4-3,ET4-8, ET4-9R2 A monolith element de-pends on few other col-umn elementsColumn summary ET1-3, ET1-4, ET1-5,ET2-4R3 A monolith element onlydepends on other serviceelementsColumn summary ET1-7, ET1-8, ET2-6,ET2-7, ET2-8, ET2-10,ET4-4, ET4-6, ET4-7R4 A monolith element hasmore dependency toother monolith elementsthan to service elementsColumn summary, Row summary ET1-6, ET2-9R5 A service element onlyhas dependencies withinother service elementsRow summary ET3-1, ET3-3, ET4-1R6 A monolith elementdoes not belong to theservice domainColumn summary, Source code ET2-11, ET3-10, ET4-5,ET4-10R7 The element is a datastructureSource code ET3-6, ET3-7, ET4-3R8 A monolith elementshould be extracted outas another serviceColumn summary, Source code ET2-11, ET3-10, ET4-5,ET4-10Table 6.1: Developer\u2019s rationale for performing extraction decisions.monolith exhibits higher coupling to other service elements. Similarly, Confirm inservice decisions are driven by the element already in service having stronger cou-pling to other elements within the service. We also observe that Confirm can arisefrom various different rationales, and it is the sole decision requiring the participantto seek extra source code information beyond what Extract prototype provides. Thesource code information was necessary to recover domain knowledge regarding thetarget element.We follow up the question by investigating whether the heuristics support de-44C MS MM CS CMDecision0510152025RationaleR1R2R3R4R5R6R7R8Figure 6.1: Extraction decision versus rationale behind.velopers in making the intended extraction decisions.Research Question I(b)Do the heuristics support the decision?As described previously in Section 5.3, the participant performed each extrac-tion task twice, once without the heuristic and again with the heuristic. In thesecond run of the task, the participant replicated the same extraction as in their firstattempt, while documenting the heuristic information that backed each of their de-cisions. Table 6.2 shows the result for each extraction task.Despite being simple and restrictive, we notice that H1 and 3 identified a signif-icant portion of move to service, confirm in service decisions. We hypothesize thatalthough the overall extraction task may be complex, when analyzed as individualiterative extraction decisions, each decision often has a straightforward solution.45The threshold-based heuristics, H4, and H5, were also able to identify someof the extraction decisions, but their success varied depending on the task at hand.Increasing H4 threshold qualified more monolith elements for copy to service de-cision, while reducing H5 threshold resulting in more being considered for confirmin monolith decision. The developer applied uniform thresholds across all casestudies; however, future research should explore how project-specific propertiesaffect the effectiveness of threshold values.We observed from Figure 6.1 that confirm in monolith decisions trace backto a variety of rationales, some of which require further domain and source codeknowledge. This need for domain knowledge is also evident in H5\u2019s inability toidentify certain confirm in monolith decisions (e.g. ET2-11, ET3-10, ET4-5, ET4-10).6.2 RQ2: Task Completion IndicatorsNext, we explore the point at which the developer determines that a final servicedesign has been achieved.Research Question IIWhat is the criteria or indicators that signal the completion of an extractiontask?The developer was permitted to make the extraction decisions in any order,and determine when the task is complete. Our goal is to identify the conditionsindicating an extraction task completion (i.e., the quality of an final service design)by analyzing the reasoning behind the developer\u2019s decision to stop making furtheriterations.In general, we observe the two goals of microservice extraction, reducingcross-boundary dependencies and eliminating circular dependencies, having a sig-nificant influence in the developer\u2019s decision to complete a task. For all extrac-tion tasks, the developer proceeded by first reviewing the points where the servicerelies on the monolith and resolving any unnecessary reliance via the extractiondecisions. The review of service\u2019s outgoing dependencies was then followed bya review of service\u2019s incoming dependencies. The developer completed the task46# Decision Heuristic Correctness1 C H4 \u27132 C H4 \u27133 C H4 \u27134 C \u2014 \u27175 MS H4 \u27176 CM H5 \u27137 MS H1 \u27138 MS H1 \u2713(a) ET1: Booking service# Decision Heuristic Correctness1 C \u2014 \u27172 C \u2014 \u27173 C \u2014 \u27174 C H4 \u27135 C \u2014 \u27176 MS H1 \u27137 MS H1 \u27138 MS H1 \u27139 CM H5 \u271310 MS H1 \u271311 CM \u2014 \u2717(b) ET2: Authorization service# Decision Heuristic Correctness1 CS H3 \u27132 C H4 \u27133 CS H3 \u27134 C H4 \u27135 C \u2014 \u27176 C H4 \u27137 C H4 \u27138 C H4 \u27139 C \u2014 \u271710 CM \u2014 \u2717(c) ET3: Account service# Decision Heuristic Correctness1 CS H3 \u27132 C \u2014 \u27173 C H4 \u27134 MS H4 \u27175 CM \u2014 \u27176 MS H1 \u27137 MS H1 \u27138 C H4 \u27139 C \u2014 \u271710 CM \u2014 \u2717(d) ET4: Quote serviceTable 6.2: Extraction decisions and correctness of heuristic support.When she has confirmed all the remaining cross-boundary dependencies, if any,were necessary and intentional. Such judgement often required domain and sourcecode knowledge.In terms of Extract UI, completion of a task was typically signified by all mono-lith elements (i.e., columns) being marked as decided. On the contrary, the comple-tion decision was less contingent on whether the row elements were fully decided.476.3 RQ3: Extraction Decision ChallengesBelow we discuss the challenges that developer faced while performing the extrac-tion tasks in the case studies and suggest potential support to can be provided asfuture work.Research Question IIIWhat factors impact the difficulty in making an extraction decision?6.3.1 Limited view of transitive dependenciesThe developer focused on immediate cross-boundary dependencies to determineif further iteration is necessary, and if so, which element to target next. However,some extraction decisions required looking beyond the immediate dependencies.For instance in ET1 and 2, the developer decided against the heuristic\u2019s suggestionto copy the method com.loader.Loader.executeSessionDB but insteadmoved the element to the service. This decision is justified by the transitive closureof executeSessionDB\u2019s dependencies. The dependency chain resolves aftermaking the subsequent decision to move com.loader.Loader.clearSessionDB.The prototype currently does not offer a transparent view of transitive depen-dencies, specifically, the transitive closure of an element\u2019s dependency. To bettersupport making such decisions, the transitive dependencies should be computedand presented for each row and column. This could be accomplished by expandingthe summary information to incorporate transitive dependencies and highlightingelements with significant transitive closures.6.3.2 To copy, to move, or to confirmWhen a monolith element was found to be extensively dependent on by serviceelements, the developer faced the decision of either copying, moving, or confirm-ing the element as is. This decision was usually more straightforward for libraryelements and more involved for source code elements. For source code elements,the decision to confirm an element required the most analysis beyond the knowl-edge presented by Extract. Confirm in monolith was chosen when the element was48considered unsuitable for the service; i.e. when its semantics belonged outsideof the service\u2019s domain, or when the developer identified another service it couldbelong in. Making these observations becomes simpler when the developer haveaccess to element\u2019s source code or domain information within the tool UI. Ratherthan purely focusing on dependency information, future iteration on the prototypeshould also consider incorporating semantics of the involved elements.The decision between copy and move required evaluating the tradeoff betweencommunication frequency and service size. This decision typically involved amonolith element that is wildly utilized by both the service and other monolithelements. When choosing to copy an element, the developer improved the separa-tion between the service and the monolith. However, there was a potential down-side of increasing the service\u2019s size due to including all transitive dependencies ofthe copied element. The developer would only make the copy decision when theincrease in service size is justified by the reduction in communication frequency.Making the copy versus move decision also benefits from further information aboutthe element, including its source code and transitive closure of its dependencies(see 6.3.1).6.3.3 Large number of interconnected elementsEven though the matrix representation of dependencies mitigated some of the com-plexity that arise from navigating graph-based information, the visualization stillresulted in significant context loss while the developer was making extraction de-cisions. When presenting a service element with high coupling to the monolith,Extract UI required the developer to scroll across many column elements to reviewall its dependencies. Likewise, when drilling down on a row element, the developerhad to navigate vertically within the table.To improve the navigability of dependency information within the UI, we canintroduce filtering ability to the rows and columns, making the identification ofspecific software element easier. Moreover, the tool can apply an ordering to thecolumns based on priority of review or temporarily hide irrelevant columns androws, focusing only on the software elements in consideration.496.3.4 Planning the next step in monolith decompositionPrior to performing any extraction task, an extraction candidate must be identified,along with its starting design. While performing bottom-up, iterative extractiontasks, it is easy to overlook the fact that these tasks collectively contribute to thecomplete decomposition of the monolith. Strategically selecting the next extractiontarget is crucial the seamless migration of a monolithic system towards a microser-vices architecture.The planning for the next extraction step involves identifying the feature thatoffers the most benefit while being the easiest to extract. In other word, the de-veloper needs to locate software elements that are highly dependent upon by manyother elements and ideally exhibit cohesion. While beyond the scope of a singleextraction task, keeping a record of the decisions made during a sequence of ex-traction tasks could aid in the identification process. For instance, noticing thatmultiple from ET1 and ET2, we observe that multiple copy decisions has beenmade for com.acmeair.services.KeyGenerator.generate element.We could decide to extract this element next in the AcmeAir decomposition pro-cess. Retaining decision records from multiple extraction tasks is challenging fora developer, but tooling could make it possible.6.4 RQ4: Tool-supported vs. Manual DesignsResearch Question IVHow do the tool-supported microservice designs compare to manually per-formed designs?To answer this question, we compare the designs of each resulting service de-signs to the corresponding services from manually performed decomposition ofAcmeAir1,2 and DayTrader3,4.1https:\/\/github.com\/blueperf\/acmeair-bookingservice-java2https:\/\/github.com\/blueperf\/acmeair-authservice-java3https:\/\/github.com\/sample-daytrader\/daytrader-accounts-service4https:\/\/github.com\/sample-daytrader\/daytrader-quotes-service506.4.1 Elements in tool-supported designsFor each software element in the tool-aided service design, we inspect its presenceor absence from the manually extracted service. An element is considered presentin the service if a functionally equivalent element exists, irrespective of its codelocation or exact class\/method name. Tables 6.3 and 6.4 provide an overview ofthis result. Note that the manually decomposed DayTrader currently only supportone out of the three modes (TradeDirect) supported by the original monolith.We limit our analysis to this particular mode.For AcmeAir monolith, we observe that Booking service has high similar-ity in terms of the elements being included, with only clearBookingDB beingexcluded from the manual extraction. The implementation of this method solelyconsisted of a call to executeBookingDB, which likely explains its omissionduring the manual extraction process. On the otherhand, we see a significant dif-ference in the tool-supported and manual designs of Authorization service.The manually extracted service contains only the code implementing login and lo-gout functionalities, without any dependency on the MongoDB database. Instead,the service seemed to have underwent further decomposition in which the sessionmanagement feature was taken out and replaced with JWT5.Additionally, we note a notable resemblance in the elements included in the twodesigns of Account and Quote services. During manual extraction Trade-Services interface was replaced with a HTTP controller class and getIn-GlobalTxn was removed as Account service had access to its own Accountdatabase. Similar to the JWT replacement in AcmeAir system, decomposition ofDayTrader also modified util.Log.* to utilize Log4j6 instead of java.util.-logging as in the original monolith. The manual designs also omitted certainlogging-related configurations by relying on the configurations provided by Log4j.6.4.2 Elements in manual designsNext, we examine the elements present in each manually extracted service and de-termine if functionally equivalent elements also exist in the Extract service design.5https:\/\/jwt.io\/6https:\/\/logging.apache.org\/log4j\/2.x\/51The manually extracted Booking service implemented an additional rewardstracking feature which was originally a shared responsibility of Flight and Customercomponents in the monolith. Instead of having direct communication betweenFlight and Customer services, the developer opted to position Booking ser-vice as a intermediary that communicates with both Flight and Customer tomanage rewards gained from a particular booking. This is likely to resolve circu-lar dependency in the extracted services. Aside from reward tracking, the manuallyextracted Booking service also implemented a health check feature. Health checkis an API exposed by Booking service allowing other services to make calls andensure that the service is live and accessible. The manual Authorization ser-vice also included a similar health checking feature, and additional code to makeexisting login, logout implementation compatible with JWT authentication.In the manual Account service of DayTrader, the only additional function-alities included were the AccountController class implementing REST end-points, and modifications to the util.Log class to utilize the Log4j library. How-ever, Quote service implemented additional market summary feature which thedeveloper decided against extracting during the case study (ET4-10). In the orig-inal DayTrader monolith, the market summary feature is managed by a singletonclass MarketSummarySingleton that depends on Quote methods. The de-veloper conducting the manual extraction chose to integrate the market summarywith the Quote feature instead of extracting it as a separate service, likely due tothe feature\u2019s relatively small size.From these comparisons, we see that while the tool-supported service designsgenerally contain elements that are consistent with the manually extracted services,the tool-supported designs are often incomplete (i.e., missing elements that existin the manually extracted services). We hypothesize that the difference is due toExtract prototype lacking support beyond a single service extraction task. The de-veloper performing manual monolith decomposition benefits from a comprehen-sive view of the entire history of previously extracted services, enabling informeddecisions that consider the system as a whole.52Element Presentservice.BookingService \u2713service.KeyGenerator.generate \u2713web.BookingsREST \u2713mongo.services.BookingServiceImpl \u2713mongo.ConnectionManager.* \u2713loader.Loader.executeBookingDB \u2713loader.Loader.clearBookingDB \u2717config.AcmeAirConfiguration.* \u2713org.mongodb \u2713org.bson \u2713(a) ET1: Booking serviceElement Presentservice.AuthService \u2713service.KeyGenerator.generate \u2717web.LoginREST \u2713web.RESTCookiesSessionFilter.doFilter \u2717mongo.services.AuthServiceImpl \u2717mongo.ConnectionManager.* \u2717loader.Loader.executeSessionDB \u2717loader.Loader.clearSessionDB \u2717config.AcmeAirConfiguration.countCustomerSession \u2717org.mongodb \u2717org.bson \u2717org.json \u2717(b) ET2: Authorization serviceTable 6.3: The elements present in Extract\u2019s designs of AcmeAir services andtheir presence in the manually extracted counterparts.53Element PresentTradeServices.* \u2717TradeActionslogin, logout, register, getAccountData, getAccountProfileData, updateAccountProfile \u2713direct.TradeDirectlogin, logout, register, getAccountData, getAccountProfileData, updateAccountProfile \u2713commit, getConn, releaseConn, rollBack getStatement, getDataSource \u2713getInGlobalTxn \u2717entities.AccountProfileDataBean \u2713entities.AccountDataBean \u2713KeySequenceDirect.getNextID \u2713KeyBlock$KeyBlockIteratorhasNext, next \u2713util.Log.* \u2717TradeConfiggetTrace, getActionTrace \u2717(a) ET3: Account serviceElement PresentTradeServices.* \u2717TradeActionsgetAllQuotes, getQuote, createQuote, updateQuotePriceVolume \u2713direct.TradeDirectgetAllQuotes, getQuote, createQuote, updateQuotePriceVolume, getQuoteData, getQuoteForUpdate \u2713getQuoteDataFromResultSet, updateQuotePriceVolumeInt \u2713commit, getConn, releaseConn, rollBack getStatement, getDataSource \u2713getInGlobalTxn, publishQuotePriceChange \u2717entities.QuoteDataBean \u2713util.Log.* \u2713TradeConfiggetUpdateQuotePrices, getPublishQuotePriceChange \u2713getTrace, getActionTrace \u2717(b) ET4: Quote serviceTable 6.4: The elements present in Extract\u2019s designs of DayTrader servicesand their presence in the manually extracted counterparts.54Chapter 7Threats to ValidityConstruct validity The use of lines of code as a measure to estimate microservicesize may not fully capture the complexity and functionality of the resulting servicedesigns. Instead of relying solely on LOCs, combining other metrics such as ser-vice interactions, coupling and cohesion, and modularity, could better capture thecomplexity and functionality of the designs.Internal validity. The author conducted the case studies as the developer, andalthough the result is based on objective observation, this introduces experimenterbias. In the second extraction attempt for each case study, heuristics were em-ployed, but the developer replicated their initial attempt and merely assessed theheuristics for their indicative ability. This approach minimizes heuristic bias, butthe result may still be influenced by the threshold value used. To enhance inter-nal validity, case studies should be conducted by external participants and considermultiple threshold values to identify any consistent patterns or biases.External validity. The case studies were performed by a single developer, andwere limited to evaluating two Java monolithic systems. While the selected mono-liths were chosen to showcase different degree of feature collocation and are com-monly used in related research, additional studies involving more participants anda broader range of Java monoliths are necessary to enhance the generalizability ofthe findings.55Chapter 8Limitations and Future WorkOur approach promotes developers to perform iterative monolith decomposition byfocusing on a single microservice extraction task. However we have identified fourmain limitations to this approach:1. Dynamic and data dependencies are not considered. The approach on staticanalysis only to retrieve coupling information of the elements relevant in theextraction task. However, alternative approaches commonly integrate run-time and data dependency information into their analysis, allowing develop-ers to obtain a more thorough view of the program. However incorporatingthese information would also complicate the extraction task as developerswould need to analyze and evaluate various types of dependencies.2. Non-code elements are not analyzed and can not be extracted. The approachonly considers code as software elements, and non-code artifacts such asdocumentation, configuration files, and test or release-related files cannot beextracted as part of the extraction task. To overcome this limitation, addi-tional research is needed to define the implicit dependencies between non-code artifacts and code elements.3. Relies on developer-input of an initial service design. The starting point ofthe approach is an initial microservice design crafted by the developer. Thisis an manual overhead specific to our approach that is not existent in al-ternative, more autonomous approaches. Nevertheless, considering another56perspective, this overhead is somewhat deliberate and compels the developerto conduct a pre-analysis for the extraction task. Our approach presupposesthat the developer possesses a certain degree of familiarity with the systemthey are decomposing.4. Approach may become an overhead with simpler microservice extraction.Manual extraction may be more appropriate if the original monolith is highlymodular and the feature being extracted is self-contained. During the pre-analysis (for devising an initial plan), The developer may come to realizationthat the task is straightforward, and proceed to manually extract the service.Given the limitations of the approach and challenges observed during the casestudies, we propose a number of improvements and extensions to our approach andthe tool prototype that we see beneficial to research in iterative monolith decom-position.1. Integration with IDE. The case studies uncovered a need for source code ref-erence while performing the extraction tasks, regardless of the dependencyinformation presented by the visualization. Developers can extract essentialdomain knowledge from the source code. Integrating with an IDE wouldfulfill this requirement without necessitating additional context switches forthe developer.2. Enhanced heuristics information. For the prototype, we introduced fiveheuristics, which, despite their simplicity, aligned with a substantial portionof the decisions made. New heuristics, such as those that take into accountmultiple extraction tasks, could be developed to assist developers in making\u201dgood\u201d decisions and avoiding \u201dbad\u201d ones.3. Incorporate test code into extraction task. We described the different typesof software code and their impact on the granularity of decisions made fora specific element (Section 3.5). Of the three types, the prototype accountsfor source and library code, but an extension should be made to test code.In general, text code relevant to a feature being extracted also belongs in theresulting service. The extracted test code could also serve the purpose of57asserting that the extraction preserves the behaviors from the original mono-lith.4. Support analysis of wider variety of dependencies. Dependencies in Javasystems are not limited to method calls. Other types of dependencies suchas field dependencies, class hierarchy dependencies (e.g., implements, in-herits), and input and return type dependencies also contribute to couplingsbetween software elements. For a more thorough analysis, extension to thesedependencies would be necessary.5. Persist decisions across multiple extraction tasks. The comparisons betweenExtract-assisted service design and manually extracted services demonstratedhow a decision in one extraction task can influence subsequent decisionsin another task. Iterative decomposition benefits the developer by breakingdown monolith decomposition into concrete extraction tasks. Nevertheless,a holistic view is crucial to make decisions that align with the overall decom-position.6. Provide more space-efficient visualizations. From the case studies, we ob-served a higher usage of row and column summaries than the cell values.This is because the current matrix visualization in the prototype replicatesdependency information both in the summary popups and the cell values.The cells do provide additional transitive dependency counts but this in-formation was underutilized by the developer. In order to provide a morespace-efficient visualization, this duplication should be reconsidered.7. Provide automated support for performing code changes. The current pro-totype produces a service design for actual extraction to be performed man-ually by the developer. The tool could be extended to assist the resultingcode changes as well, once the service design is approved by the developer.For example, the tool could generate an API layer based on the remainingcross-boundary dependencies between the service and the monolith. Furtherresearch into automated source code modification could enable such exten-sion.58Chapter 9ConclusionMonolith decomposition is a complex task that brings system-wide changes. Weidentified a disparity between the decomposition process supported by currentstate-of-the-art tools and how a developer would usually approach this kind ofdecomposition. The current automated decomposition tools introduce big-bangrewrites to the system, which contradicts with the developer\u2019s iterative decomposi-tion workflow. We have presented the Extract prototype for supporting developerbetter in such iterative decomposition process. Drawing inspiration from researchin feature extraction and dependency analysis tools, we specialized Extract for rea-soning about a single microservice extraction task. Extract supports the developerin constructing a microservoice design by presenting a focused view of softwareelement dependencies, providing an interface for making extraction decisions oneach relevant element, and suggesting plausible decisions by means of heuristics.We performed four case studies which illustrate the usage of the Extract pro-totype against two open-source monolithic Java systems. The case studies showthat using Extract, the participant can produce microservice designs that are con-sistent with manually performed extractions. By analyzing the type and sequenceof extraction decisions in each case study, we provide insights into the factors in-fluencing each decision, the criteria for task completion, and the challenges facedduring the extraction process.Our bottom-up, iterative microservice extraction approach divides monolith de-composition into smaller, tractable tasks that are less intrusive to a live monolithic59application. This approach is applicable to various forms of system decomposi-tion, extending beyond the domain of monolith decomposition and microservices.Extension to the approach should incorporate knowledge from multiple extractiontasks, in order to better inform decisions that span across individual extractiontasks.60Bibliography[1] C. Brandt and A. Zaidman. Developer-centric test amplification. EmpiricalSoftware Engineering, 27(96), 2022. doi:10.1007\/s10664-021-10094-2. \u2192page 7[2] C. Cadar, D. Dunbar, D. R. Engler, et al. Klee: Unassisted and automaticgeneration of high-coverage tests for complex systems programs. In OSDI,volume 8, pages 209\u2013224, 2008. \u2192 page 7[3] P. Calc\u00b8ado. Building products at soundcloud, part 2: Breaking the monolith,6 2014. URL https:\/\/developers.soundcloud.com\/blog\/building-products-at-soundcloud-part-2-breaking-the-monolith. \u2192 pages1, 2[4] J. M. Carroll. Human-computer interaction: Psychology as a science ofdesign. Annual Review of Psychology, 48(1):61\u201383, 1997.doi:10.1146\/annurev.psych.48.1.61. URLhttps:\/\/doi.org\/10.1146\/annurev.psych.48.1.61. PMID: 15012476. \u2192 page 7[5] K. Chen and V. Rajlich. Case study of feature location using dependencegraph. In International Workshop on Program Comprehension, pages241\u2013247. IEEE, 2000. \u2192 page 6[6] T. Eisenbarth, R. Koschke, and D. Simon. Locating features in source code.IEEE Transactions on Software Engineering, 29(3):210\u2013224, 2003.doi:10.1109\/TSE.2003.1183929. \u2192 page 6[7] S. Eski and F. Buzluca. An automatic extraction approach: Transition tomicroservices architecture from monolithic application. In Proceedings ofthe International Conference on Agile Software Development: Companion,New York, NY, USA, 2018. ISBN 9781450364225.doi:10.1145\/3234152.3234195. URLhttps:\/\/doi.org\/10.1145\/3234152.3234195. \u2192 pages 2, 461[8] R. Falke, R. Klein, R. Koschke, and J. Quante. The dominance tree invisualizing software dependencies. In International Workshop onVisualizing Software for Understanding and Analysis, pages 1\u20136, 2005.doi:10.1109\/VISSOF.2005.1684311. \u2192 page 9[9] M. Fowler. Strangler fig application, 2004. URLhttps:\/\/martinfowler.com\/bliki\/StranglerFigApplication.html. \u2192 page 2[10] M. Fowler and J. Lewis. Microservices: A definition of this newarchitectural term. 2014. URLhttps:\/\/martinfowler.com\/articles\/microservices.html. \u2192 page 1[11] G. Fraser and A. Arcuri. Evosuite: On the challenges of test case generationin the real world. In International Conference on Software Testing,Verification and Validation, pages 362\u2013369, 2013.doi:10.1109\/ICST.2013.51. \u2192 page 7[12] M. Ghoniem, J.-D. Fekete, and P. Castagliola. A comparison of thereadability of graphs using node-link and matrix-based representations. InSymposium on Information Visualization, pages 17\u201324, 2004.doi:10.1109\/INFVIS.2004.1. \u2192 page 9[13] A. Gluck. Microservice architecture at uber, 7 2020. URLhttps:\/\/www.uber.com\/en-CA\/blog\/microservice-architecture\/. \u2192 page 1[14] G. Granchelli, M. Cardarelli, P. Di Francesco, I. Malavolta, L. Iovino, andA. Di Salle. Microart: A software architecture recovery tool for maintainingmicroservice-based systems. In 2017 IEEE International Conference onSoftware Architecture Workshops (ICSAW), pages 298\u2013302, 2017.doi:10.1109\/ICSAW.2017.9. \u2192 page 11[15] I. Herman, G. Melancon, and M. Marshall. Graph visualization andnavigation in information visualization: A survey. Transactions onVisualization and Computer Graphics (TOG), 6(1):24\u201343, 2000.doi:10.1109\/2945.841119. \u2192 page 8[16] R. Holmes and R. J. Walker. Systematizing pragmatic software reuse. ACMTrans. Softw. Eng. Methodol., 21(4), 2 2013. ISSN 1049-331X.doi:10.1145\/2377656.2377657. URLhttps:\/\/doi.org\/10.1145\/2377656.2377657. \u2192 pages 6, 8, 9[17] A. K. Kalia, J. Xiao, R. Krishna, S. Sinha, M. Vukovic, and D. Banerjee.Mono2micro: A practical and effective tool for decomposing monolithic62java applications to microservices. In Proceedings of the Joint Meeting onEuropean Software Engineering Conference and Symposium on theFoundations of Software Engineering, ESEC\/FSE 2021, page 1214\u20131224,New York, NY, USA, 2021. doi:10.1145\/3468264.3473915. URLhttps:\/\/doi.org\/10.1145\/3468264.3473915. \u2192 pages 2, 4, 11[18] K. Kobayashi, M. Kamimura, K. Yano, K. Kato, and A. Matsuo. Sarf map:Visualizing software architecture from feature and layer viewpoints. InInternational Conference on Program Comprehension (ICPC), pages 43\u201352,2013. doi:10.1109\/ICPC.2013.6613832. \u2192 page 9[19] A. Krause, C. Zirkelbach, W. Hasselbring, S. Lenga, and D. Kro\u00a8ger.Microservice decomposition via static and dynamic analysis of the monolith.In International Conference on Software Architecture Companion (ICSA-C),pages 9\u201316, 2020. doi:10.1109\/ICSA-C50368.2020.00011. \u2192 pages 2, 4, 9[20] J. Laval and S. Ducasse. Resolving cyclic dependencies between packageswith enriched dependency structural matrix. Software: Practice andExperience, 44(2):235\u2013257, 2014. doi:https:\/\/doi.org\/10.1002\/spe.2164.URL https:\/\/onlinelibrary.wiley.com\/doi\/abs\/10.1002\/spe.2164. \u2192 page 9[21] T. Mauro. Microservices at netflix: Architectural best practices, 2 2016.URL https:\/\/www.nginx.com\/blog\/microservices-at-netflix-architectural-best-practices\/.\u2192 page 1[22] G. Mazlami, J. Cito, and P. Leitner. Extraction of microservices frommonolithic software architectures. In International Conference on WebServices (ICWS), pages 524\u2013531, 2017. doi:10.1109\/ICWS.2017.61. \u2192pages 2, 4, 5[23] T. Mens and T. Tourwe. A survey of software refactoring. Transactions onSoftware Engineering (TSE), 30(2):126\u2013139, 2004.doi:10.1109\/TSE.2004.1265817. \u2192 page 1[24] R. Nakazawa, T. Ueda, M. Enoki, and H. Horii. Visualization tool fordesigning microservices with the monolith-first approach. In WorkingConference on Software Visualization (VISSOFT), pages 32\u201342, 2018.doi:10.1109\/VISSOFT.2018.00012. \u2192 pages 2, 4, 5[25] S. Newman. Monolith to Microservices: Evolutionary Patterns to TransformYour Monolith. O\u2019Reilly Media, 2019. \u2192 pages 1, 263[26] J. O\u2019Hanley. Package by feature, not layer, Jan 2023. URLhttp:\/\/www.javapractices.com\/topic\/TopicAction.do?Id=205#:\u223c:text=Package%2Dby%2Dfeature%20uses%20packages,with%20minimal%20coupling%20between%20packages. \u2192 page 18[27] I. Pigazzini, F. A. Fontana, V. Lenarduzzi, and D. Taibi. Towardsmicroservice smells detection. In Proceedings of the InternationalConference on Technical Debt, TechDebt, page 92\u201397, New York, NY, USA,2020. doi:10.1145\/3387906.3388625. URLhttps:\/\/doi.org\/10.1145\/3387906.3388625. \u2192 page 15[28] M. Pinzger, K. Grafenhain, P. Knab, and H. C. Gall. A tool for visualunderstanding of source code dependencies. In International Conference onProgram Comprehension (ICPC), pages 254\u2013259, 2008.doi:10.1109\/ICPC.2008.23. \u2192 page 8[29] F. Ponce, G. Ma\u00b4rquez, and H. Astudillo. Migrating from monolithicarchitecture to microservices: A rapid review. In International Conferenceof the Chilean Computer Science Society (SCCC), pages 1\u20137, 2019.doi:10.1109\/SCCC49216.2019.8966423. \u2192 page 4[30] D. Qi, A. Roychoudhury, Z. Liang, and K. Vaswani. Darwin: An approachto debugging evolving programs. ACM Transactions on SoftwareEngineering and Methodology (TOSEM), 21(3):1\u201329, 2012. \u2192 page 7[31] C. Richardson. Strangler fig application pattern: Incremental modernizationto services, June 2023. URLhttps:\/\/microservices.io\/post\/refactoring\/2023\/06\/21\/strangler-fig-application-pattern-incremental-modernization-to-services.html. \u2192 page 2[32] M. P. Robillard and G. C. Murphy. Representing concerns in source code.ACM Trans. Softw. Eng. Methodol., 16(1):3\u2013es, 2 2007. ISSN 1049-331X.doi:10.1145\/1189748.1189751. URLhttps:\/\/doi.org\/10.1145\/1189748.1189751. \u2192 page 6[33] Z. M. Saul, V. Filkov, P. Devanbu, and C. Bird. Recommending randomwalks. In Proceedings of the the joint meeting of the European softwareengineering conference and the ACM SIGSOFT symposium on Thefoundations of software engineering (ESEC\/FSE), pages 15\u201324, 2007. \u2192page 664[34] R. Schaut. Mac word 6.0, 2 2004. URLhttps:\/\/web.archive.org\/web\/20160412213959\/https:\/\/blogs.msdn.microsoft.com\/rick schaut\/2004\/02\/26\/mac-word-6-0\/. \u2192page 1[35] C. Schro\u00a8er, F. Kruse, and J. Marx Go\u00b4mez. A qualitative literature review onmicroservices identification approaches. In S. Dustdar, editor,Service-Oriented Computing, pages 151\u2013168, Cham, 2020. SpringerInternational Publishing. \u2192 page 2[36] K. Sellami, M. A. Saied, A. Ouni, and R. Abdalkareem. Combining staticand dynamic analysis to decompose monolithic application intomicroservices. In J. Troya, B. Medjahed, M. Piattini, L. Yao, P. Ferna\u00b4ndez,and A. Ruiz-Corte\u00b4s, editors, Service-Oriented Computing, pages 203\u2013218,2022. \u2192 pages 2, 4[37] K. Sen and G. Agha. CUTE and jCUTE: Concolic unit testing and explicitpath model-checking tools: (tool paper). In Computer Aided Verification:International Conference, (CAV), August 17-20, 2006. Proceedings 18,pages 419\u2013423, 2006. \u2192 page 7[38] M. Shahin, P. Liang, and M. A. Babar. A systematic review of softwarearchitecture visualization techniques. Journal of Systems and Software(JSS), 94:161\u2013185, 2014. ISSN 0164-1212.doi:https:\/\/doi.org\/10.1016\/j.jss.2014.03.071. URLhttps:\/\/www.sciencedirect.com\/science\/article\/pii\/S0164121214000831. \u2192pages 8, 9[39] H. P. Singh, V. Kumar, and A. Agrawal. Demystifying informationtechnology projects success and failure factors: The cases of californiaDMV and bancoitamarati bank. Mumukshu Journal of Humanities, 7(1):493\u2013499, 2015. \u2192 page 1[40] J. Spolsky. Things you should never do, part i, 4 2000. URL https:\/\/www.joelonsoftware.com\/2000\/04\/06\/things-you-should-never-do-part-i\/.\u2192 page 1[41] S. Staffa, G. Quattrocchi, A. Margara, and G. Cugola. Pangaea:Semi-automated monolith decomposition into microservices. In H. Hacid,O. Kao, M. Mecella, N. Moha, and H.-y. Paik, editors, Service-OrientedComputing, pages 830\u2013838. Springer International Publishing, 2021. \u2192pages 2, 465[42] H. Zhang, S. Li, Z. Jia, C. Zhong, and C. Zhang. Microservice architecturein reality: An industrial inquiry. In International Conference on SoftwareArchitecture (ICSA), pages 51\u201360, 2019. doi:10.1109\/ICSA.2019.00014. \u2192page 266","attrs":{"lang":"en","ns":"http:\/\/www.w3.org\/2009\/08\/skos-reference\/skos.html#note","classmap":"oc:AnnotationContainer"},"iri":"http:\/\/www.w3.org\/2009\/08\/skos-reference\/skos.html#note","explain":"Simple Knowledge Organisation System; Notes are used to provide information relating to SKOS concepts. There is no restriction on the nature of this information, e.g., it could be plain text, hypertext, or an image; it could be a definition, information about the scope of a concept, editorial information, or any other type of information."}],"Genre":[{"label":"Genre","value":"Thesis\/Dissertation","attrs":{"lang":"en","ns":"http:\/\/www.europeana.eu\/schemas\/edm\/hasType","classmap":"dpla:SourceResource","property":"edm:hasType"},"iri":"http:\/\/www.europeana.eu\/schemas\/edm\/hasType","explain":"A Europeana Data Model Property; This property relates a resource with the concepts it belongs to in a suitable type system such as MIME or any thesaurus that captures categories of objects in a given field. It does NOT capture aboutness"}],"GraduationDate":[{"label":"Graduation Date","value":"2023-11","attrs":{"lang":"en","ns":"http:\/\/vivoweb.org\/ontology\/core#dateIssued","classmap":"vivo:DateTimeValue","property":"vivo:dateIssued"},"iri":"http:\/\/vivoweb.org\/ontology\/core#dateIssued","explain":"VIVO-ISF Ontology V1.6 Property; Date Optional Time Value, DateTime+Timezone Preferred "}],"IsShownAt":[{"label":"DOI","value":"10.14288\/1.0435520","attrs":{"lang":"en","ns":"http:\/\/www.europeana.eu\/schemas\/edm\/isShownAt","classmap":"edm:WebResource","property":"edm:isShownAt"},"iri":"http:\/\/www.europeana.eu\/schemas\/edm\/isShownAt","explain":"A Europeana Data Model Property; An unambiguous URL reference to the digital object on the provider\u2019s website in its full information context."}],"Language":[{"label":"Language","value":"eng","attrs":{"lang":"en","ns":"http:\/\/purl.org\/dc\/terms\/language","classmap":"dpla:SourceResource","property":"dcterms:language"},"iri":"http:\/\/purl.org\/dc\/terms\/language","explain":"A Dublin Core Terms Property; A language of the resource.; Recommended best practice is to use a controlled vocabulary such as RFC 4646 [RFC4646]."}],"Program":[{"label":"Program (Theses)","value":"Computer Science","attrs":{"lang":"en","ns":"https:\/\/open.library.ubc.ca\/terms#degreeDiscipline","classmap":"oc:ThesisDescription","property":"oc:degreeDiscipline"},"iri":"https:\/\/open.library.ubc.ca\/terms#degreeDiscipline","explain":"UBC Open Collections Metadata Components; Local Field; Indicates the program for which the degree was granted."}],"Provider":[{"label":"Provider","value":"Vancouver : University of British Columbia Library","attrs":{"lang":"en","ns":"http:\/\/www.europeana.eu\/schemas\/edm\/provider","classmap":"ore:Aggregation","property":"edm:provider"},"iri":"http:\/\/www.europeana.eu\/schemas\/edm\/provider","explain":"A Europeana Data Model Property; The name or identifier of the organization who delivers data directly to an aggregation service (e.g. Europeana)"}],"Publisher":[{"label":"Publisher","value":"University of British Columbia","attrs":{"lang":"en","ns":"http:\/\/purl.org\/dc\/terms\/publisher","classmap":"dpla:SourceResource","property":"dcterms:publisher"},"iri":"http:\/\/purl.org\/dc\/terms\/publisher","explain":"A Dublin Core Terms Property; An entity responsible for making the resource available.; Examples of a Publisher include a person, an organization, or a service."}],"Rights":[{"label":"Rights","value":"Attribution-NonCommercial-NoDerivatives 4.0 International","attrs":{"lang":"*","ns":"http:\/\/purl.org\/dc\/terms\/rights","classmap":"edm:WebResource","property":"dcterms:rights"},"iri":"http:\/\/purl.org\/dc\/terms\/rights","explain":"A Dublin Core Terms Property; Information about rights held in and over the resource.; Typically, rights information includes a statement about various property rights associated with the resource, including intellectual property rights."}],"RightsURI":[{"label":"Rights URI","value":"http:\/\/creativecommons.org\/licenses\/by-nc-nd\/4.0\/","attrs":{"lang":"*","ns":"https:\/\/open.library.ubc.ca\/terms#rightsURI","classmap":"oc:PublicationDescription","property":"oc:rightsURI"},"iri":"https:\/\/open.library.ubc.ca\/terms#rightsURI","explain":"UBC Open Collections Metadata Components; Local Field; Indicates the Creative Commons license url."}],"ScholarlyLevel":[{"label":"Scholarly Level","value":"Graduate","attrs":{"lang":"en","ns":"https:\/\/open.library.ubc.ca\/terms#scholarLevel","classmap":"oc:PublicationDescription","property":"oc:scholarLevel"},"iri":"https:\/\/open.library.ubc.ca\/terms#scholarLevel","explain":"UBC Open Collections Metadata Components; Local Field; Identifies the scholarly level of the author(s)\/creator(s)."}],"Supervisor":[{"label":"Supervisor","value":"Holmes, Reid","attrs":{"lang":"en","ns":"http:\/\/purl.org\/dc\/terms\/contributor","classmap":"vivo:AdvisingRelationship","property":"dcterms:contributor"},"iri":"http:\/\/purl.org\/dc\/terms\/contributor","explain":"A Dublin Core Terms Property; An entity responsible for making contributions to the resource.; Examples of a Contributor include a person, an organization, or a service."}],"Title":[{"label":"Title ","value":"Extract : informing microservice extraction decisions from the bottom-up","attrs":{"lang":"en","ns":"http:\/\/purl.org\/dc\/terms\/title","classmap":"dpla:SourceResource","property":"dcterms:title"},"iri":"http:\/\/purl.org\/dc\/terms\/title","explain":"A Dublin Core Terms Property; The name given to the resource."}],"Type":[{"label":"Type","value":"Text","attrs":{"lang":"en","ns":"http:\/\/purl.org\/dc\/terms\/type","classmap":"dpla:SourceResource","property":"dcterms:type"},"iri":"http:\/\/purl.org\/dc\/terms\/type","explain":"A Dublin Core Terms Property; The nature or genre of the resource.; Recommended best practice is to use a controlled vocabulary such as the DCMI Type Vocabulary [DCMITYPE]. To describe the file format, physical medium, or dimensions of the resource, use the Format element."}],"URI":[{"label":"URI","value":"http:\/\/hdl.handle.net\/2429\/85558","attrs":{"lang":"en","ns":"https:\/\/open.library.ubc.ca\/terms#identifierURI","classmap":"oc:PublicationDescription","property":"oc:identifierURI"},"iri":"https:\/\/open.library.ubc.ca\/terms#identifierURI","explain":"UBC Open Collections Metadata Components; Local Field; Indicates the handle for item record."}],"SortDate":[{"label":"Sort Date","value":"2023-12-31 AD","attrs":{"lang":"en","ns":"http:\/\/purl.org\/dc\/terms\/date","classmap":"oc:InternalResource","property":"dcterms:date"},"iri":"http:\/\/purl.org\/dc\/terms\/date","explain":"A Dublin Core Elements Property; A point or period of time associated with an event in the lifecycle of the resource.; Date may be used to express temporal information at any level of granularity. Recommended best practice is to use an encoding scheme, such as the W3CDTF profile of ISO 8601 [W3CDTF].; A point or period of time associated with an event in the lifecycle of the resource.; Date may be used to express temporal information at any level of granularity. Recommended best practice is to use an encoding scheme, such as the W3CDTF profile of ISO 8601 [W3CDTF]."}]}