IN
DEGREE PROJECT COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS
STOCKHOLM SWEDEN 2020,
Developing a Framework to
measure Enterprise Architecture Debts
PARUMITA SAHA
KTH ROYAL INSTITUTE OF TECHNOLOGY
MASTER THESIS
Supervisor
Simon Hacks EECS, KTH
Examin er
Robert Lagerstr¨om EECS, KTH
Developing a Framework to measure Enterprise Architecture Debts
KTH Royal Institute of Technology
Parumita Saha
October 2020
Utveckling av ramverk f¨or m¨atning av f¨oretagsarkitekturskuld
Parumita Saha Oktober 2020
EXAMENSARBETE Handledare
Simon Hacks EECS, KTH Examinator
Robert Lagerstr¨om EECS, KTH
Abstract
Technical debt is used to describe the changing or to maintain a system due to expedi- ent shortcuts done during its development. In the context of the software development industry, technical debt is regarded as a critical issue in terms of the negative conse- quences such as increased software development cost, low product quality, decreased maintainability, and slowed progress to the long-term success of developing software.
Code Smells are well informed in the domain of Technical Debt. They indicate to the common bad practices that may impair the future quality of the software system. By identifying those Code Smells, it is possible to give an improved solution or make the developers aware of a possible deficiency. I explore the premise that technical debt within the enterprise should be viewed as a tool. Extensible and Appropriate tools can check the Code Smells automatically and improve the quality assessment accordingly.
However, in the field of Enterprise Architecture(EA), common bad habits in EA can be called EA Smells. EA Smells itself can be a component of EA Debt. Enterprise Architecture Debt can be defined as such a metric that depicts the deviation of the currently present state of an enterprise from a hypothetical ideal state.
In this thesis, we introduce SmellCull as an extensible tool for capturing, tracking and managing Enterprise Architecture debt in the EA field. SmellCull allows measuring different kinds of Enterprise Architecture debts for EA Model. SmellCull is extensible since different types of Model can be integrated as input into the tool environment and provides developers with a lightweight tool to capture EA debt and make it easier to understand them indicating corresponding parts in the implementation. The tool is used to create propagation paths for the EA debt. This allows for an up-to-date and accurate presentation of EA debt to be upheld, which enables developer conducted implementation-level micromanagement as well as higher-level debt management.
Since the tool is sophisticated enough, automated detection supports the design pro- cess and ongoing change of EAS(Enterprise Architecture System). This includes the strategic development of EAS with the corresponding roadmaps, as well as design as- surance and performance monitoring to assess the quality of data in EA repositories and the compliance with certain standards defined by EA Smells.
Due to the limited scope of master thesis, the tool will identify a few number of EA debt. At the end, some future work suggestions in the context of identifying more salable Enterprise Architecture Debts with this tool are given.
Keywords: Technical Debt, Enterprise Architecture debt (EAD), Code Smells, En- terprise Architecture Model(EAM), Enterprise Architecture Tool(EAT).
Sammanfattning
Teknisk skuld dvs d˚alig eller kortsiktig programutveckling som belastning p˚a IT-sys- tem m˚aste f¨orr eller senare ˚aterbetalas. I industrin betraktas teknisk skuld som en kritisk fr˚aga n¨ar det g¨aller de negativa konsekvenserna som ¨okad mjukvaruutveck- lingskostnad, l˚ag produktkvalitet, minska underh˚all och l˚angsammare framsteg till den l˚angsiktiga framg˚angen med att utveckla programvara.
D˚alig kodkvalitet “code smell” ¨ar vanligt f¨orekommande teknisk skuld. Det uppkom- mer i vanliga d˚aliga metoder “anti-patterns” som f¨ors¨amrar programvarans framtida kvalitet. F¨or att kunna identifiera bristande kodkvalitet ¨ar det m¨ojligt att skapa en f¨orb¨attrad l¨osning eller g¨ora utvecklare medvetna om de m¨ojliga bristerna. Jag un- ders¨oker f¨oruts¨attningarna att en s˚adan teknisk skuld i f¨oretag b¨or unders¨okas med en programvara. Utbyggbara och ¨andam˚alsenliga programvaror kan analysera k¨allkod och hitta var kvaliteten beh¨over f¨orb¨attras.
F¨oretagens tekniska skuld kan definieras som ett m˚att som visar avvikelsen fr˚an ett hypotetiskt idealtillst˚and genom att j¨amf¨ora det aktuella tillst˚andet med praktiska rekommendationer “best practice”.
I detta examensarbete introducerar jag SmellCull som ett utbyggbart verktyg f¨or att hitta, sp˚ara och hantera bristf¨allig kodkvalitet inom företagsarkitektur (EA). SmellCull till˚ater m¨atning av olika typer av tekiska skulder f¨or EA modellen. SmellCull ¨ar utbyggbart genom att olika typer av datamodeller kan integreras som indata i milj¨on, och det ger utveck-lare ett l¨att verktyg f¨or att hantera teknisk skuld i programmeringsprojekt och hj¨alpa projektdeltagarna i programmeringsprojekt att f¨orst˚a vad orsakar brister i kodkvalitet.
Eftersom verktyget ¨ar tillr¨ackligt sofistikerat finns det automatiserad sp˚arning, de- signprocess och kontinuerlig f¨orb¨attring av EAS (Enterprise Architecture System).
Detta inkluderar strategisk utveckling av EAS med motsvarande f¨ardplan, samt kon- struktionss¨akerhet och prestanda¨overvakning f¨or att bed¨oma kvaliteten p˚a data i EA f¨orvar och efterlevnaden av vissa standarder som definieras av EA code smell detec- tion.
P˚a grund av den begr¨ansade omfattningen av examensarbetet kommer verktyget att
identifiera n˚agra f˚a EA skuld. I slutet, n˚agra framtida arbetsf¨orslag i samband med identifiering mer s¨aljbara f¨oretagsarkitekturskulder med detta verktyg ges.
Nyckelord: Teknisk skuld, f¨oretagsarkitekturskuld, företagsarkitektur (EA), EA- verktyg.
Acknowledgements
In the beginning, I would like to thank Robert Lagerstr¨om for reviewing this thesis.
Special thanks go to my supervisor, Simon Hacks, for his input, continuous feedback and valuable suggestions during the development of this work. The given critiques have been appreciated. Last but not least I am very grateful to Simon for the inspi- ration because he has always been to me. Without him the result would not have been the same.
Finally, I thank my family, friends, near and dear ones for providing me with constant support during this thesis.
Thank You.
Parumita Saha
Contents
1 Introduction 16
1.1 Motivation . . . 16
1.2 Goals . . . 17
1.3 Background . . . 17
1.3.1 Enterprise Architecture . . . 17
1.3.2 Multilevel Modelling . . . 19
1.3.3 Technical Debt . . . 21
1.3.4 Enterprise Architecture Debt . . . 22
1.3.5 Code Smell . . . 23
1.4 Research Questions . . . 23
1.5 Delimitations . . . 24
2 Related Work 26 2.1 Enterprise Architecture Model Quality Framework & Tool . . . 26
2.2 Different types of Debt Management tool . . . 27
3 Effectively utilizing Life Cycle 29 3.1 Project life-cycle management . . . 29
3.2 The principle of Scrum . . . 33
3.3 Scrum Phase . . . 35
3.4 Piloting Scrum Practices . . . 37
4 Implementations 39 4.1 Challenges & Requirements . . . 39
4.2 Structure of the SmellCull . . . 40
4.3 EADebt Detection using SmellCull . . . 42
4.4 Automation of SmellCull . . . 45
4.5 SmellCull Web Application . . . 51
4.6 Limitations . . . 53
5 Evaluation 55 5.1 Evaluation based on an Automatic Oracle . . . 55
5.2 Evaluation based on Developer’s Judgment . . . 56
5.3 Evaluating the Accuracy of SmellCull Tool . . . 57
5.4 Demonstration on different EA Smells . . . 58
6 Discussion 62 6.1 Application in EA Development . . . 62
6.2 Benefits . . . 63
7 Conclusion 65 7.1 Summary . . . 65
7.2 Future Work . . . 66
7.2.1 Mechanism Improvement & Validation . . . 66
7.2.2 Extending the Range of Supported Techniques . . . 67
A Code Smell Website . . . 69
B EA Smell Website . . . 74
References . . . 85
List of Tables
4.1 List of Code Smells/Antipatterns . . . 43
List of Figures
1.1 A collaboration among Business, Technology & Operation . . . 18
1.2 Enterprise Architecture as a Cross-layer View of . . . 19
1.3 Architecture scales for measuring complexity. Adapted from Sessions & Salingaros. (a) Functionality levels[27] . . . 20
1.4 Architecture scales for measuring complexity. Adapted from Sessions & Salingaros. (b) dependency levels[27] . . . 20
1.5 The technical debt landscape. On the left, evolution or its challenges; on the right, quality issues, both internal and external.[39] . . . 21
1.6 Relation Between Technical Debt & EA Debt as a sub-domain of Tech- nical Debt . . . 22
3.1 Output with SDLC and Avoiding SDLC . . . 30
3.2 Scrum Process[19] . . . 34
3.3 Scrum Methodology . . . 35
4.1 Different parts of SmellCull Architecture . . . 41
4.2 Sequence Diagram from High Level view . . . 46
4.3 Using Multilevel Modelling to create Customized Model . . . 47
4.4 An illustration of combining models into pojoModel . . . 48
4.5 Automation Process using UML Class Diagram . . . 50
4.6 Welcome page of Web Application . . . 51
4.7 Scenario after uploading the files . . . 52
4.8 Identification of EA Debts . . . 53
5.1 EA Debt for different Domain of Model . . . 57
5.2 Dead Component at “Deprecated Process” . . . 59
5.3 Shared Persistency at “Passenger database” . . . 60
5.4 Weekend Modularity at “Airline administration support” . . . 61
1 Code Smell Website page 1 of 4 . . . 69
2 Code Smell Website page 2 of 4 . . . 70
3 Code Smell Website page 3 of 4 . . . 71
4 Code Smell Website page 4 of 4 . . . 72
5 EA Smell Website page 1 of 4 . . . 74
6 EA Smell Website page 2 of 4 . . . 75 7 EA Smell Website page 3 of 4 . . . 76 8 EA Smell Website page 4 of 4 . . . 77
Acronyms and Abbreviations
Acronyms Abbreviations
EA Enterprise Architecture
EAD Enterprise Architecture Debt EAT Enterprise Architecture Tool
ATAM Architecture Tradeoff Analysis Method
TD Technical Debt
DM Debt Management
EAS Enterprise Architecture Smell
MM Multilevel Modelling
ER Entity Relationship
C2SADEL Chiron-2 Software Architecture Description and Evolution Language
DD Database Design
R&D Research and Development
APM Agile Project Management
EAF Enterprise Architecture Framework
EAQF Enterprise Architecture Model Quality Framework
Acronyms Abbreviations
SDLC Software Development Life Cycle RAD Rapid Application Development
CI Continuous Integration
IT Information Technology
CS Code Smell
EAM Enterprise Architecture Model
CE Concurrent Engineering
XSD Open Group ArchiMate Model Exchange File Format Standard EXCEL Electronic Xylophones Create Electronic Listening
EADMF Enterprise Architecture Debt Management Framework
DL Detector List
JDK Java Development Kit
DI Detector Item
EAS Enterprise Architecture Systems JAXB Java Architecture for XML Binding
IR Information Retrieval
XML Extensible Markup Language
Web App Web Application
UE User Experience
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
Chapter 1 Introduction
Introduction can be claimed as the most important part of any report or presentation;
the introduction presents a problem, the reason why it has to be solved, what is necessary information to solve the problem and what is not considered part of the problem. This introduction first introduces Motivation and Goals; then background literature, followed by research questions; finally narrates about the delimitation.
Rounding up is the outline of the project report.
1.1 Motivation
In the software development industry, technical debt is regarded as a critical issue in terms of the negative consequences such as increased software development cost, low product quality, decreased maintainability, and slowed progress to the long-term success of developing software[82][16]. Technical debt narrates the delayed technical development activities for getting short-term payoffs such as a timely release of spe- cific software[92]. For the last few years, technical debt in system development has received rising attention as a result of a growing need to handle the degrading quality of software and avoid costly re-engineering and maintenance.
However, it is vital to align Information Technology(IT) and business in order to realize the full benefits and potentials of those IT investments[54]. From there, the concept of Enterprise Architecture (EA) has evolved as a method to facilitate the alignment of IT systems and business strategies within dynamic and complex organizations[91]. Consequently, the huge interest in EA resulted in vast scientific contributions that address a broad thematic spectrum, including EA frameworks, EA management, and EA tools[25]. Adapting the concept of technical debt in the EA domain, a new metaphor “Enterprise Architecture debt (EAD)” has been proposed recently to provide a holistic view[29].
In the real world,Technical debt is not necessarily a negative thing to incur, same
goes to EA debt to be held in an enterprise. The danger of debt comes into place when there is no proper debt management approach to prioritize, which debt should be repaid as soon as possible. Code smells can be an indicator of factors that contribute to technical debt[90]. Code Smells are certain structures in the code that indicate violation of fundamental design principles and negatively impact design quality. Code smells are usually not bugs; they are not technically incorrect and do not prevent the program from functioning[62]. Instead, they indicate weaknesses in design that may slow down development or increase the risk of bugs or failures in the future. Trans- ferring the concept of Code Smells to the domain EA Debts is called EA Smells[71].
Enterprise Architecture Smells can be a component of EA Debt[71]. While EA Smells can be identified on its design state, then developers can rely on it or even afterward resulting in a quality of data in EA repositories[71]. EA Smells can be seen as a counterpart for Code Smells. They serve as negative examples and bad habits that impair the quality of an EA when ignored. They are seemingly good solutions or typ- ical mistakes, known not to provide any satisfactory results, such that corresponding symptoms, causes, consequences and solutions should be mentioned[71].
There is an absence of an extensible framework to Enterprise Architecture Debts whilst technical debt framework is readily discussed in the software industry. So it becomes crucial to develop a tool and methodologies to bridge the gap between the academic and practitioner communities concerning the nature of the EA debt. In this thesis, SmellCull as an extensible tool has been introduced for capturing, tracking and managing Enterprise Architecture debt in the EA field. SmellCull allows measuring different kinds of Enterprise Architecture debts for EA Model. The tool will identify the EA Debt with extensible architecture, introduce a multilevel-modeling, increase the quality of Enterprise Architecture Systems(EAS) and practices to avoid these common bad habits.
1.2 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes into place when there is no proper debt management approach to prioritize. This thesis aims to provide the framework for an extensible tool that allows measuring different kinds of EA debts, also provide techniques that it can be extended in future.
1.3 Background
1.3.1 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways. Among those, Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
tiple definitions of EA[29]. Therefore, I regard EA as a set of artifacts, which are aggregated. Kappelman pointed out that “The ‘enterprise’ portion of EA is under- stood by some as a synonym to ‘enterprise systems’, yet by others as equivalent to
‘business’ or ‘organization’[29]. Even less uniform is the understanding of the mean- ing of ‘architecture’. The most common understanding of the term is a collection of artifacts (models, descriptions, etc.) that define the standards of how the en- terprise should function or provide an as-is model of the enterprise”. However, EA helps to face “ongoing and disruptive change” by attempting to align IT and business strategy[29].
Enterprise Architecture is a complete expression of the enterprise, a master plan which ”acts as a collaboration force” between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of au- tomation such as information systems and databases and the enabling technological infrastructure of the business such as computers, operating systems and networks[72].
Figure 1.1 is showing the collaboration among Business, Technology & Operation.
In a large modern enterprise a rigorously defined framework is necessary to be able to capture a vision of the ”entire organisation” in all its dimensions and complexity[72].
Enterprise Architecture is a program supported by frameworks which is able to coor- dinate the many facets that make up the fundamental essence of an enterprise at a holistic way.
Figure 1.1: A collaboration among Business, Technology & Operation
A fundamental principle that can be applied to EA is : ”Always design a thing considering it in its next larger context - a chair in a room, a room in a house, a house in an environment, an environment in a city plan”[72].
From the above analysis it has been clear that the definitions can vary, But Enterprise
Architecture usually includes several different layers of the enterprise.A schematic illustration can be seen in Figure 1.2 with the proposed Layers of Business Archi- tecture, Process Architecture, Integration Architecture, Software Architecture and Technology Architecture. Winter and Fischer introduced a scheme based on the foundation that “Most of the artifacts [. . . ] in EA can be represented as aggre- gation hierarchies”. The different domains of EA interact with each other, while the components of each corresponding domain are organized in their own hierarchies[87].
Figure 1.2: Enterprise Architecture as a Cross-layer View of Aggregate Artifacts by Winter and Fischer[87]
1.3.2 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practice is its inability to cope with complexity. With large numbers of entities, data models become difficult to understand and maintain. The problem becomes unmanageable at the enterprise level, where models typically consist of hundreds of entities. A number of approaches have been proposed in the literature to address this problem, but none have achieved widespread acceptance in practice[49]. The Model may be organized into any number of levels, depending on its complexity[49]. The technique is called multilevel modeling which is based on the organization of a city street directory, which is a practical solution to the problem of representing a large and complex model in everyday life[49].In this thesis, Multilevel Modelling has been used to build our cus- tomised model which provides the platform to integrate different types of model.
Multi-level modeling (also called deep metamodelling) extends the standard approach to metamodelling by enabling modeling at an arbitrary number of meta-levels[43].
Multi-level models are particularly appropriate for research designs where data for participants are organized at more than one level. While the lowest level of data in multi-level models is usually an individual. The highest level of data is compared with the previous model to assess better model fit.
Figure 1.3: Architecture scales for measuring complexity. Adapted from Sessions &
Salingaros. (a) Functionality levels[27]
Figure 1.4: Architecture scales for measuring complexity. Adapted from Sessions &
Salingaros. (b) dependency levels[27]
Multi-level models can be applied on data with many levels. Figure 1.3 and Figure 1.4] shows functionality and dependency in multi-level model. In this project, we also use Multilevel Modelling by making a customised model to implement the extensible framework. This thesis uses a Model with multiple level because it leads to simpler model descriptions[43]. Here it will also make data distribution and model modification easy.
1.3.3 Technical Debt
In the field of software development industry, Technical Debt is considered as a crit- ical issue in terms of the negative outcomes such as increased software development cost, low product quality, decreased maintainability, and delayed progress to the long- term attainment of developing software.[81] [16]. Technical Debt narrates the delayed technical development activities for getting short-term payoffs such as a timely re- lease of a specific software[93]. Seaman described Technical Debt as a situation in which software developers allow compromises in one dimension to meet an immediate demand in another dimension and resulted in higher costs to restore the health of the system in future[74].
Moreover, Technical Debt is explained as the effect of immature software artifacts, which requires extra effort on software maintenance in the future[28]. While the Technical Debt metaphor has further extended to include design debt, which de- scribes the immature design decisions[4], the context of Technical Debt is still limited to the technological aspects.
Figure 1.5: The technical debt landscape. On the left, evolution or its challenges; on the right, quality issues, both internal and external.[39]
Figure 1.5 shows a possible formation of a technical debt landscape. Visible elements such as new functionality to add and defects to fix, and the invisible elements (or rather, those visible only to developers) can be distinguished here. On the left, it is dealing primarily with evolution or its challenges, whereas on the right, it is
dealing with quality issues, both internal and external. Technical Debt often refers to invisible elements.
1.3.4 Enterprise Architecture Debt
However, the concept of Technical Debt that specifically focuses on technical aspects demonstrates a deficiency of attention to attaining a holistic perspective to locate the alignment between business and IT aspects. Whilst enterprise architecture (EA) is gaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currently present state of an enterprise from a hypothetical ideal state. EA Debt arises, when debt is taken in an artifact, which an EA consists of. This means that an element is not implemented or executed optimally in relation to the supposed ideal situation.
Taking debt in a low hierarchy, can be helpful and pay off, but it has to be “repaid”
in accordance to business related goals. Otherwise the whole EA would rely on that debt and use faulty or considered bad artifacts. This entails a high risk of additional debt and hinders the development. EA Debt is further increased by bad interfaces or bad interoperability and different priorities of stakeholders, not conform with an EA that is considered good by evaluation approaches[29].
Figure 1.6: Relation Between Technical Debt & EA Debt as a sub-domain of Technical Debt
Further, we can relate Technical Debt to EA Debt as a sub-domain of it (cf.
Figure 1.6) that is related to the software and technology aspects. However, there are also issues related to EA Debts on software and technology aspects that are still not covered by Technical Debt. Those issues can be interalia their relations among each other or the adherence to overarching business goals[29].
1.3.5 Code Smell
Code smells are symptoms of poor design and implementation choice. It has been the subject of several empirical studies mainly intended at characterizing them and at measuring their impact on the maintainability of software systems. It is well-informed that smells tend to hinder code comprehensibility[3] and maintainability[77][89][88]) as well as to increase change- and defect-proneness [38][37]. The definition is given by Fowler and Beck such as “certain structures in the code that suggest (sometimes they scream for) the possibility of refactoring” [24] are common bad habits that can impair the quality of a software system or the software architecture when they are ignored. Like anti-patterns, they are seemingly good solutions that are commonly and repeatedly used but known not to provide any satisfactory results.
Along with those, smells comes something like software evolvability or maintain- ability. IEEE defined software maintainability as “the ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or to adapt to a changed environment”[1]. M¨antyl¨a and Lassenius adapted this term to software evolvability which refers to “the ease of further developing a software element” [48]. This has a close match with the term perfective software main- tenance of IEEE which is defined as “software maintenance performed to improve the performance, maintainability, or other attributes of a computer program”[1].
Some reasons for happening Code smells has been observed:
• Defect of Software design in the time of creation.
• As a result of maintenance and evolution activities.
• When new features and enhancing functions are added.
• For the pressure of production , developers tends to do mistakes in development.
• Excessive use of design patterns can also be a cause.
1.4 Research Questions
To develop an extensible tool that will detect EA Smells automatically, there are some steps which have to be taken into account. These research questions will guide the process of finding suitable answers to the open problems and structure the course of action.
• Question1: How the architecture of this tool should be sketched that is robust to future extensions ?
• Question2: What type of input format should be chosen for the tool ?
• Question3: How the tool could be more generalized for different types of EA Model?
• Question4: What the EA debt detection tool will do in the field of Enterprise Architecture ?
• Question5: Does any Web service APIs such as REST-API could be integrate- able to the tool environment?
1.5 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model and not the entire Enterprise Architecture. The attention will paid mostly to the Enter- prise Architecture Components, relationships, interconnections and hierarchy between them. The excluded parts are methods, process flow etc. The project is not respon- sible for supporting statistics, processes and management of the EA systems, the project is bounded only for supporting the Enterprise Architecture Model at basic, advanced and research levels.
On account of our resource and time limitation, the investigations were confined only to the following EA debt :
• Ambiguous Viewpoint
• Chatty Service
• Cyclic Dependency
• Data Service
• Dead Component
• Dense Structure
• Documentation
• Duplication
• Hub-like Modularization
• Lazy Component
• Message Chain
• Shared Persistency
• Strict Layers Violation
• Weakened Modularity
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a model’s quality directly, So different topics have to be investigated. The chapter is divided into two different categories. First, studies that occupy the framework analysis regarding EA models. The next section mentions various types of Enterprise Architecture Tool available on the market and how this thesis can extend prior work.
2.1 Enterprise Architecture Model Quality Frame- work & Tool
Before proceedings, the concept of model quality should also be clear because Smell- Cull tool will be used to identify different types of EA Smells within EA models. An Enterprise Architecture Model Quality Framework (EAQF) was developed by Timm et al. that structures relevant information and helps enterprise architects to reflect on their EA models[80]. This framework constracts upon six principles to assess an enterprise model’s quality by Becker, Probandt, and Vering, namely the principles of validity, relevance, economic efficiency, clarity, systematic model structure and comparability[33]. Besides, Pitschke provides a list of quality attributes and explains them in relation to business process models[64].
A very popular framework for ascertaining the success of information systems is The DeLone and McLean Model of Information Systems Success, most lately updated in 2003[18]. This was adapted specifically to the domain of EA by Lange, Mendling, and Recker depicting EA product quality, EA function setup quality, EA service delivery and EA cultural aspects as components influencing the satisfaction and the intention of use[41].
A tool developed by Robert Lagerstr¨om using a probabilistic mathematical frame- work is demonstrated for analysis of enterprise architecture models[20].The tool guides the creation of information system scenarios in the form of enterprise architecture models and calculates assessments of the scenarios as they evolve. This tool focuses
on evaluating maintainability not evaluating system inter-operability[20].
A framework for enterprise service interoperability analysis and a metamodel con- taining the information needed to perform the analysis is suggested by Johan Ull- berg, Robert Lagerstr¨om and Pontus Johnson[84]. They contribute a metamodel that supports the creation of enterprise architecture models amenable to service interop- erability analysis.The metamodel consists of entities with accompanying attributes that can be used to create enterprise architecture models from which it is possible to extract precisely the information that is needed for quantitative enterprise service interoperability analysis.Another enterprise architecture metamodel for maintainabil- ity modeling and analysis is presented Robert Lagerstr¨om[70].
Recently Johannes Salenti has introduced EA debt concept and shown some EA debt detection technique on EA model. But it is mostly a catalog related to EA smells not any framework for any tool of EA debt detection[71].
2.2 Different types of Debt Management tool
Since, a tool to identify EA debt will be developed, some debt dedicated tools which managing and identifying TD should be analysed. This will give us an overall idea regarding Debt detection tool and also how can proceed to make a tool. A number of debt detection and management tools are available on the market. Few numbers of them are following bellow:
Software maps tool is one of the debt management tool for Monitoring code quality and development activity by software maps[12]. This provides automated software analysis and monitoring of both quality-related code metrics and development activ- ities by means of software maps. A software map represents an adaptive, hierarchical representation of software implementation artifacts such as source code files being organized in a modular hierarchy. The maps can express and combine information about software development, software quality, and system dynamics; they can sys- tematically be specified, automatically generated, and organized by templates. The maps aim at supporting decision-making processes[12].
Within debt management area, Tracker Tool is used for cataloging Technical debt(TD).
The tool allows tabulating and managing Technical debt properties in order to sup- port managers in the decision process. It also allows managers to track TD. The approach is implemented by TD-Tracker tool, which can integrate different TD iden- tification tools and identified debts[22].
Recently DebtFlag has been proposed for capturing, tracking and resolving technical debt in software projects. DebtFlag integrates into the development environment and
provides developers with lightweight documentation tools to capture technical debt and link them to corresponding parts in the implementation. But in the perspective of Enterprise Architecture domain, existing concept of DebtFlag is not appropriate[31].
Another Debt management tool is Sonar TD plugin for dentifying and measuring TD in the form of low code coverage, design, violations, complexity, comments[55].
But none of the related work has developed any framework for an extensible tool to identify Enterprise Architecture Debt(EA Debt). In this thesis I have developed a framework to measure Enterprise Architecture Debts.
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degree project. Explained first is the general Software Process Model method with their pros and cons. Also why Scrum has been chosen to which this degree project adheres to. The second section(5.2) described principle of Scrum and third section(5.3) are regarding the Scrum phase. Lastly follows the Scrum throughout the whole project in order to achieve the results.
3.1 Project life-cycle management
Projects are challenged with cost pressure, decreasing cycle time and very rapid tech- nology and feature evolution. At the same time, IT companies have overloaded their R&D capacity and capability with many technologies, complex roadmaps of multiple variants and unclear value contributions of products and new features[19]. Project life-cycle management is still insufficiently practiced.
On the other hand, projects run without concrete and quantitative objectives and without tracking where they are with respect to expectations. Project proposals are evaluated in isolation from other ongoing activities. Projects are started or stopped based on local criteria, not considering the global trade-offs across all projects and opportunities. Only one-third of all software engineering companies have techniques to effectively share knowledge on their products and development projects [19].
Figure 3.1 shows the outcome with Software Development Life Cycle(SDLC) and without SDLC for universal project. Ours is also a common project and for the de- velopment of our project, it is essential to maintain quality, consistency and delivery.
The achievement of our project will be a tool that is about a software product. Prod- ucts are of a more permanent nature than a project forasmuch as products continue to exist long after the project that delivered it has closed. Therefore, the SDLC provides guidelines for supporting the product post-production. Procedures include practices
for knowledge transfer, Code turnover. It is a entire circle in a system’s life. So to follow SDLC will be beneficial for the future development of our tool[47].
Figure 3.1: Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used. These are Waterfall model, V-shaped model, Spiral model, Prototype model, Rapid applica- tion development model (RAD), Evolutionary development, Incremental model, It- erative model, Rational Unified Process (RUP), Big Bang Model, DevOps, Lean
etc[66][67][15][17][69].
Neither of the waterfall model nor the Spiral model deals well with frequent change.
The Waterfall model assumes that once you are done with a phase, all issues covered in that phase are closed and cannot be reopened. The Spiral model can deal with changes between phases, but once inside a phase, no change is allowed[50].
The V-shaped model is very rigid, like the waterfall model. Little flexibility and adjusting scope are difficult and expensive. Software is developed during the imple- mentation phase, so no early prototypes of the software are produced. The model does not provide a clear path. As a result, problems found during the testing phase[66].
The milestone of iterative model is more ambiguous than the waterfall. Activities performed in parallel are subject to miscommunication and mistaken assumptions.
Unforeseen inter-dependencies can create problems. Changes are possible as it is an iterative model[66].
Incremental model starts with an initial planning and ends with deployment with the cyclic interactions in between. Easier to test and debug during a smaller iter- ation. But each iteration phase is rigid and does not overlap each other and also requires a good planning designing. RAD Model is flexible and adaptable to changes but its is more complex to manage comparing to other models[67].
The lean SDLC methodology mostly focuses on reducing waste. If developers and operations people do not establish clear lines of communication and transparency from the start, the security of the software might suffer, leading to crippling setbacks and can be a major disadvantage of DevOps[15]. RUP needs for integration of com- ponents later ; its a major disadvantage[17]. Big bang model is a high-risk model; if the requirements are misunderstood in the beginning, you could get to the end and realize the project may have to be started all over again[69].
In comparison to others, Agile model is gaining popularity in the industry, although they compromise a mix of accepted and controversial software engineering practices.
It’s typically more suitable for smaller projects and it’s not preferred for long-term projects where you have to know every tiny detail[7]. The software industry would most probably find that specific project characteristic such as the objective, scope, requirements, resources, architecture and size will determine which methodology suits them best. In the previous years, anecdotal evidence and success stories from prac- ticing professionals suggest that agile methods are effective and feasible for many situations and environments. Agile model supports individuals and interactions over processes and tools. Agile models bounds to work with comprehensive documenta- tion. And the objective of Agile Testing is to find defects and fix them immediately.
It includes Customer collaboration over contract negotiation and allows changes over following a plan[34].
When an appropriate model is applied according to the requirements, the success rate of software projects can increase. There is no perfect model existing. Everything depends upon the project and its characteristics like nature of the project, developer’s skills and management support[6].
In our project, it’s essential to move quickly and easily and to respond swiftly to change. Our project involves Continuous Integration (CI), which indicates keeping the code up to date by producing a clean build of the system a few times per day.
This project support with a rule stating that the programmer never leaves anything unintegrated at the end of the day; it gives the authority to deliver a product version suitable for release at any moment. What to do is to minimize the time and effort required by each integration.
It’s a small project consist of 2 members while one involves ‘driving’ (coding, imple- mentation, etc.) and the other ‘navigates’ (such as observing, providing feedback).
Every process of the project is added to meet the requirements. The time duration is not long-termed and approximately six months. This project needs iterations like multiple releases and delivers the complete product at the end of the final iteration.
Implement, test, repeat and then release are needed to provide the framework. So it can be called iterations. From the perspective of testing, we need to find defects and fix them immediately. This project is developing a framework. So, a flexible approach is the searching to product development. For these reasons, agile model is chosen as the project development life cycle.
In the area of project management, the term “agile management” became known from the development of a set of processes developed specifically for the area of soft- ware, such as Scrum (Schwaber and Beedle, 2001), Adaptive Software Development (Highsmith, 2000) and Extreme Programming (Beck, 1999). These processes were named “agile” , and their creators got together and prepared a manifesto, which was called the Manifesto for Agile Software Development[83].
Since then, several studies have been conducted on the topic of “agility”, and these processes have become known under the general acronym for agile project manage- ment (APM) [14]. Scram methodology has been used in our project because of it is an adaptive, iterative, fast, flexible, and effective methodology designed to deliver significant value quickly and throughout a project development[21].
3.2 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown in Figure 3.2.
• Product Backlog - This is the prioritized list of all features and changes that have yet to be made to the system desired by multiple actors, such as cus- tomers, marketing and sales and project team. The Product Owner is liable for maintaining the Product Backlog.
• Sprints - Sprints are usually between 14 and 30 days in length, it is the proce- dure of adapting to the changing environmental variables (requirements, time, resources, knowledge, technology etc) and must result in a potentially ship- pable increment of software. The working tools of the team are Sprint Planning Meetings, Sprint Backlog and Daily Scrum meetings[51].
• Sprint Planning meeting – Sprint planning meeting is first attended by the customers, users, management, Product Owner and Scrum Team where a set of goals and functionality are decided on. Next, the Scrum Master and the Scrum Team focus on how the product is implemented during the Sprint[51].
• Sprint Backlog – It is the list of features that is currently assigned to a particular Sprint. When all the features are completed a new iteration of the system is delivered[51].
• Daily Scrum – It is a daily meeting for approximately 15 to 30 minutes, which provides enough time to address obstacles, but does not allow time to brainstorm a solution[30].
Figure 3.2: Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum project team notably. For example, the project manager, i.e., the Scrum Master, does no longer needs to organize the team, but the team organizes itself and makes decisions on what to do. Ken Schwaber illustrates, “Most management is used to directing the project, telling the team what to do and then ensuring they do it. Scrum relies on self-organization, with the team deciding what to do while management runs inter- ference and removes roadblocks” [34] .
Scrum has been successfully used over thousands of projects in 50 organizations pro- ducing significant productivity improvement. Rising and Janof suggest that “Clearly, Scrum is not an approach for large, complex team structures, but found that even small, isolated teams on a large project could make use of some elements of Scrum.
This is true process diversity”.
3.3 Scrum Phase
Figure 3.3: Scrum Methodology
Figure 3.3 shows the main phases and steps of the SCRUM methodology.
Each of the phases has the following steps:
Planning
The first step is making the backlog - a list of essential properties that have to be implemented during the development process. The product owner is a person respon- sible for this. He bases on information from customers, situation on the market and competition requirements and knows which functions or properties of the product are the most needed. Next points such as the delivery date, the number and function- ality of release, the most important releases(selection), the list of packets(objects) for backlog items, the project team structure, Necessary tools, Risk control, Release cost(including not only a development process but also the cost of training or mar- keting) should also be discussed[73].
This phase of the Scrum process is very broad if the product is new but if it is an existing system that need to be enhanced(by adding some new functions)it will bring the phase to quite brief analysis[73].
Architecture/High Level Design
After the planning, It is time for the system architecture. The team review the back- log, think what changes have to be made to implement new properties and design the implementation process. Sometimes, as it was said before, there is a need to make some changes, refine the old product, learn some additional knowledge, analysis, solve problems or issues which appear during the process. In the end, there are designed review meetings during which the teams exchange information, present progress and problems, reassigned changes as required[73].
Development (Sprint)
The Development phase is an iterative cycle of development work. Management fixes that time, competition, quality or functionality are met, iterations are and the closure phase occurs. This approach is also called as Concurrent Engineering.[73].
Development consists of the following macro processes:
• Meeting with teams to review release plans.
• Distribution, review and adjustment of the standards with which the product will conform.
• Iterative Sprints, until the product is deemed ready for distribution.
A Sprint is a set of development activities directed over a predefined period, usually one to four weeks. The interval is decided on product complexity, risk assessment and degree of oversight wished for. Sprint speed and intensity are led by the selected duration of the Sprint. Risk is assessed continuously and adequate risk controls and responses put in place. Every individual Sprint consists of one or more teams execut- ing develop, wrap, review and adjust phase.
Develop: Defining changes wanted for the implementation of backlog requirements into packets, opening the packets, performing domain analysis, designing, developing, implementing, testing, and documenting the changes. Development consists of the micro process of discovery, invention, and implementation[73].
Wrap: Closing the packets, creating a executable version of changes and how they implement backlog requirements[73].
Review: All teams meeting to present work and review progress, raising and resolv- ing issues and problems, adding new backlog items. Risk is reviewed and appropriate responses defined[73].
Adjust: Consolidating the information gathered from the review meeting into af- fected packets, including different look and feel and new properties[73].
Closure:When the management team realizes that the variables of time, compe- tition, requirements, cost, and quality concur for a new release, they declare the release ”closed” and enter this phase. This phase prepares the developed product for general release. Integration, system test, user documentation, training material preparation, and marketing material preparation are among closure tasks[73].
3.4 Piloting Scrum Practices
The meta-level process that has followed to facilitate scrum in our project is out- lined below sequentially. There are usually different subjective (opinion-based) con- siderations that have balanced with negotiations between the various stake-holders (supervisor & student) of this project.
• In the beginning, the prioritized list of all features and changes such as make the framework extensible has chosen; data will be structured and accessed using a customised model(see ”pojoModel” package in Figure 4.5), remove the de- pendency from auto-created model(see ”model” package in Figure 4.5), should be added a monitoring panel. Also, define the delivery date and functional- ity of one or more releases. These plannings are described within our project proposals which has been submitted in March.
• To architect high level design, domain analysis has performed to the extent required like literature review and research analysis of previous work to build, enhance or update the domain models to reflect the new system context and requirements. Refine the architecture again to support the new context and requirements. And the problems or issues in developing and implementing the changes are identified.
• Our Sprints are 14-days in length and each Sprint contains a Planning Meetings.
In every sprint, the procedure of adapting to the changes has been discussed and must result in an upgrade of the project. Sprint planning meeting is attended by supervisor & student where a set of goals and functionality are decided on.
The Scrum Master was the supervisor throughout the whole sprints.
• As our thesis is a remote work environment due to the COVID-19 pandemic, so the sprint work has been spilled into some small parts as the result of Daily Scrum meetings. Obstacles are faced by the team and to keep track of the progress, mail communication has been used. For the version control mecha- nism, github has been used.
• Each Sprint consists of develop, wrap, review and adjust phase.
• Discovery, invention, developing, implementing, testing and documenting the changes has been followed for develop phase. I have developed new changes or the backlog in develop phase. I am responsible for maintaining the Backlog.
• In the warp phase of our project, Creating an executable version of changes was the main target.
• Work and review progress, raising and resolving issues and problems, adding new backlog items has been presented in sprint meetings for review. Risk is reviewed and appropriate responses are defined also.
• Adjust phase has been done by consolidating the information gathered from the review, including different look and feel and new properties.
• For closing a phase, It has been addressed that the gaps between promised fea- tures and what was delivered. When the activities of a process are finalized or complete then a phase can enter to the closure phase. As an example, I de- fined ”closed” for the pojoModel implementation when the must have features, integration, testing has been completed.
Chapter 4
Implementations
After defining the EA Smells, it is now time to draft the tool that is capable of detecting smells. First, some challenges and general requirements are mentioned in section 4.1 before explaining the basic structure of the SmellCull in section 4.2.
The list of EA Smells currently detected by the tool has demonstrated in section 4.3. The implementation of the tool is Dissected in section 4.4. ; then showing the interaction between user and tools in section 4.5. Finally, limitations to the program and automatic detection in general are presented(section 4.6).
4.1 Challenges & Requirements
Our objective is to build a tool (Smellcull), which can collect the Enterprise Archi- tecture (EA) Model from a website and publish the EA Debt after processing on the input. The tool should be intuitive enough to for non-technical users, detect the 14 EA smells accurately and efficient in processing the inputs.
The EA model can be compliant with windows XML format. XML should be created using appropriate protocols and the XML has a certain format.The XML file should be provided by the user by maintaining this certain format. The validator will check the XML either it is valid or not. In case of invalid , The system will show a error and it will not execute further process of EA Debt detection.This is a critical issue because the sources of information that can be exploited will be based on this XML file.
Transformation rules and mapping should be followed for model-to-model transfor- mation. Data exchange between auto created model to customised model should be done very carefully through another Layer. However, the multilevel modelling of this mechanism can lead to rather complex strategy for very simple tasks. From the analysis of the state of the art, a set of rule as well algorithm has implemented for evaluating EA Model.
Since one has to be able to easily modify existing and add new detection strategy to the current algorithm for new smells, the opportunity to run tests or the program itself has to be given in a clear and uncomplicated manner. Again one can extend dif- ferent types of model as input by adding new transformation rules and more features on the customised model. In particular for customised Model one can analyze the structural dependencies between the entities of classes, i.e., attributes and methods, in order to build, for each entity, the entity set, i.e., the set of methods using it.
Still, the detection of many smells can be challenging, because the functionality is not implemented directly within any source, such that no similar indications meth- ods are available. Hence, too little information can be apparent to detect specific smells automatically, which asks for manual assessment.More investigation, analysis and technique regarding EA smells identification is needed to handle these challenges.
4.2 Structure of the SmellCull
The structure for the SmellCull mechanism is based onto the documentation struc- ture introduced as part of the EA Debt Management Framework (EADMF) [5] by Simon Hacks. This structure is extended in the SmellCull mechanism in order to decompose entries into reusable components as well as to properly present Enterprise Architecture debt at the implementation level.
The SmellCull is a four parted approach on managing EA debt with a more holistic view of the enterprise. Every part will be discussed here in succession. SmellCull maps all of the parts as a framework and how they relate and interact to fulfill thesis mission. Figure 4.1 shows the major parts(The blue filled rectangle) , sub-parts(The white filled rectangle), data flow(both one-sided and two sided arrow) of the Smell- Cull .
In the first, the SmellCull starts with web application(webapp) part. Details about this part will be discussed later in section 4.5. It will act like more likely User In- terface(UI) and rest of the parts will be used for Identification Processing. Welcome page(Figure 4.6) of webapp will handle input files and Thanks page(Figure 4.8) of webapp will visualize the results of Identification Processing.
Another part is the SmellCull customised model.SmellCull takes a set of informa- tion for EA Model. A description explains the model’s structure including relation, elements, property, strategy , organisation, view etc. for its acquirance. An estimate for the model’s principal indicates how much resources are required to pay it back - to make this partition fully adhere to the design.Here the model can be popularised either using auto-created model or the documents. dataExchange Layer has been
used to transform the data from auto-created model to customised model.
Next, SmellCull relies onto a Detector List(DL). The list is populated with smells which can be called Detector Items(DIs), which correspond to single atomic occur- rences of EA debt in the model. A Detector Item(DI) upholds one EA smell.
By allowing DIs to be constructed with Detector List, a degree of freedom has pre- served so that more EA smells can be added as DI in the DL as well as more identi- fication technique can be integrated. A DI’s location is not limited to a single area predefined by the implementation technique, but rather it can encompass an unlim- ited amount within Enterprise Architecture and combination of them. This makes it possible for a single DI to have unrestricted propagation capabilities. At the same time, the possibility to use any critical issue as equals to DI is kept.
Figure 4.1: Different parts of SmellCull Architecture
Finally, the fourth part are smells used to identify different EA Debt Item. This part will marking out the location and give a description regarding where and how the EA Debt is found. The rule of Identifying each Debt Item is different and separate. It includes a name like Ambiguous Viewpoint and a identification rule for it. The name is self-explanatory. The rules will be applied to the Customised model according to the DL.
4.3 EADebt Detection using SmellCull
In total 56 Code Smells are from different sources[13][9].Among them 30+ anti- patterns defined in the literature [24][46], only for a subset of them has approached and the tool for their automatic identification. Table 4.1 reports the list of such code smells as well as anti-patterns detected by the SmellCull, while the description of Anti-pattern has been given. Specifically, for each anti-pattern present (i) its defi- nition; (ii) Alases; and (iii) the sources where its found .
Very often code bad smells and anti-pattern are used as synonym. However, the table we represent also allows to understand the difference between code smells and anti-patterns. Specifically, code smell represents something “probably wrong” in the code, while an anti-pattern is certainly a design problem in source code. In other words, a code smell might indicate an anti-pattern[10]
Table 4.1: List of Code Smells/Antipatterns Antipattern
Name
Description Aliases Sources
Ambiguous Viewpoint
Object-oriented analysis and de- sign (OOA & D) models are of- ten presented without clarifying the viewpoint represented by the model.This is called Ambiguous Viewpoint.
[2]
Chatty Service Chatty Service is an antipattern where a high number of operations are required to complete one ab- straction where the operations are typically attribute-level setters or getters
CRUDy Inter- face, Maybe It is Not RPC
[59],[56], [57], [52], [60]
Cyclic Depen- dency
A cyclic chain of calls between mi- croservices exists
Cyclic Hierar- chy, Cyclically- dependent
Modularization
[78], [68], [32], [53]
Data Service Data Service typically contains ac- cessor operations, i.e., getters and setters. In a distributed environ- ment, some services that may only perform some simple information retrieval or data access operations.
A Data Service usually deals with very small messages of primitive types and may have high data co- hesion.
Data Class [85], [48], [61], [76], [9],[24], [59], [56], [57]
Dead Compo- nent
A variable, parameter, field, method or class is no longer used (usually because it’s obsolete).
Dead Code [24], [85], [48],[32], [56], [57], [2], [46]
Dense Structure This smell arises when a configu- ration code repository has exces- sive and dense dependencies with- out any particular structure.
[75]
Documentation This smells happens for unneces- sary and long documentation
Antipattern Name
Description Aliases Sources
Duplication Corresponds to a set of highly sim- ilar services
Duplicated
Code, Too
many Cooks, Unfactored Hier- archy, Software Cloning, Clip- board Coding
[24], [85], [48], [32], [9]
, [46]
Hub-like Modu- larization
This smell arises when an abstrac- tion has dependencies (both in- coming and outgoing) with a large number of other abstractions
Bottleneck Ser- vice
[9], [53], [60]
Lazy Component A class, methods or attribute that does not do anything
Lazy Class, Poltergeist, Freeloader, Unnecessary Ab- straction, Gypsy, Proliferation of Classes, ig DoIt Controller Class
[9], [24], [85],[48], [75], [46], [76], [9]
Message Chain Watch out for long sequences of method calls or temporary vari- ables to get routine data. Inter- mediaries are dependencies in dis- guise
Percolating Pro- cess, Service Chain
[24], [32], [53], [85], [48], [76], [9]
Shared Persis- tency
Different microservices access the same relational database. In the worst case, different services ac- cess the same entities of the same relational database.
Data Ownership [79]
Strict Layers Vi- olation
This violation very often occurs in the real world, although the model itself defined the layers and pro- cesses precisely. Of course there may be implicit relations that can be derived which actually connect two separate layers
[46]
Weakened Mod- ularity
Each module must strive for high cohesion and low coupling. This smell arises when a module ex- hibits high coupling and low co- hesion.
The Knot, Ar- tificial Coupling, Code at Wrong Level of Abstrac- tion
[60], [32], [53], [75]
4.4 Automation of SmellCull
Figure 4.2 represents the basic functionalities of the tool through a Sequence Di- agram. It is an interaction diagram that describes how operations are carried out here. They capture the interaction between objects in the context of a collaboration.
Sequence Diagrams are time focus and they show the order of the interaction visually by using the vertical axis of the diagram to represent time what messages are sent and when[11]
This project is implemented through System sandwich approach which is an ingenious approach for building and maintaining software or tool. The idea is to sandwich the system between a front-end interface (e.g., written in a fourth generation language) and a back-end process. The front-end interacts with the user [8]. Dynamic func- tionality of the SmellCull mechanism relies on Back-end and Front-end. Automation process depends on Backend and Pre-Processing as well as Post-Processing depends on Front-end. Backend will be described in this section which is the Automation Process and will recite Frontend in the next subsection(section 4.5).
The Automation process is organized as a maven project[23], which allows for au- tomated testing, building and packaging of the source code. The Java Development Kit (JDK) 11 is used, because it supports the xjc tool for auto generating classes from the ArchiMate schema (archimate3_Diagram.xsd).The auto generated classes of the model are located in a separate package (see “model” package in Figure 4.5).
On top of those generated classes, the Java Architecture for XML Binding (JAXB) can be used to load an XML instance of a model and bind it to the classes. This process is called unmarshalling and provides the content of the XML-file as objects (class JAXBMarshalUnmarshal).
Figure 4.2: Sequence Diagram from High Level view
For making the tool extensible, transferring the data to a customized model as new type of model can be adjustable for the requirements. For instance the auto generated model is created using xjc tool and XML binding is used to load an XML instance of a model, one can add new approaches for binding or new model which can be transformed to the customised model. But this can not be done by using only auto generated Model. This is because every classes of auto generated Model(see
“model” package in Figure 4.5 is auto created and not modifiable according to the requirements of the tool. The classes of the customised model are located in another package (see “pojoModel” package in Figure 4.5).
To create the customized model(see ”pojoModel” package in Figure 4.5) we have applied model-to-model transformation and then used multilevel modeling(see Fig- ure 4.3). In Figure 4.3, it is clear that motivation and strategy belongs to higher level because they are organizations’ specific goals oriented and rest of the others including element, property, structure, relations, view are within lower level. As only one auto generated model right now exists, so transformation has done between auto generated model-to- customised model. But the foundations for achieving model-to- model transformation have not yet been built[86]. Normally, model transformation rules are built on the basis of model mappings, and model mappings concern seman- tic or syntactic representations. One of the difficulties in achieving model-to-model mappings and transformations lies in detecting the semantics and semantic relations that are conveyed in different models. Both of the semantic and syntactic checking measurements are combined into auto created model-to-customised model mappings and transformations[86]. In addition, other auto-created model can also be integrated to the customised model(see ”pojoModel” package in Figure 4.5).
Figure 4.3: Using Multilevel Modelling to create Customized Model
Figure 4.4: An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange is used here.It will facilitate the use of customised model classes and provide additional functionality that is employed by the Detectors, a ModelAdapter(see ”adapter” pack- age in Figure 4.5) is created as a layer of indirection. It uses the JAXB class for unmarshalling the provided model to Java objects. As a consequence, the complex structure of the customised model(see ”pojoModel” package in Figure 4.5) gets hid- den by more intuitive methods. The class EASmellDetector(see ”adapter” package in Figure 4.5) manages all Detectors and calls their detect methods and transfer the results to the HelloController (see ”main” package in Figure 4.5). HelloController provides information to the user by printing all collected EA Smells through the Web Application(Figure 4.8). In the next subsection(section 4.5), web application part will be described in details. When executing the program, one has to specify at least the EA Model instance (as XML-File) that is to be checked, and optionally as second argument the schema to verify against (as XSD-File).
For each smell there is a separate detector class located in the smells package (see
“smells” package in Figure 4.5) that extends the abstract class Detector. This way the individual classes can be modified or extended conveniently. A Detector has a reference to the model under investigation, as well as the list of detected smells and the actual smell name. In addition, different constants for metrics can be accessed from the Constants class that encompasses different thresholds in one place. When, eventually, a smell was detected by the detect() method, a new EASmell with its name, the affected element and an optional context like metric values can be added to the smells list.
Overall, the detection of smells is based on metrics and general architecture analy- sis.The specific detection methods for each EA smells are implemented in smells pack- age using separate classes like AmbiguousViewpoint, WeekenedModularity etc.(see
“smells” package in Figure 4.5).
Figure 4.5: Automation Process using UML Class Diagram
4.5 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica- tion framework. The Spring Boot 2.1.6 is used, because the Spring Boot provides a good platform for Java and our project is also build in Java.
Figure 4.6, Figure 4.7 and Figure 4.8 depicts the SmellCull web application. From the first page, Entering a Enterprise Architecture model and validator both as input set we can start the application.
Figure 4.6: Welcome page of Web Application
After uploading the necessary file, the web application look like Figure 4.7. The submit button contains the main controls. From here it is possible to begin the procedure of detecting EA debt. The EA debt results will be followed by the docu- mentation of EA smell detector list. This list has been configured, categorized and described in Section 4.3.
Figure 4.7: Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 4.8) contains detailed results for detector list. Here the representation contains the critical issues called EA debt described in Section 4.3. The critical issue in terms of the negative conse- quences such as increased software development cost, low product quality, decreased maintainability, and slowed progress to the long-term success of developing software.
Now the critical issues can be handled by the technical development activities of a specific Enterprise Architecture. From here, it is easy to see the reasoning for why an EA Debt for a particular Model element has happened.
Figure 4.8: Identification of EA Debts
4.6 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EA model) not the entire Enterprise Architecture. This is an unwanted side effect.
The program only works for EA models compliant to The Open Group ArchiMate Model Exchange File Format Standard of the archimate3_Diagram.xsd . Anyway, the detection methods can be applied to other models as well, but this particular implementation relies on the described structure.
The SmellCull mechanism relies onto the EA models which will be provided by user.
This indicates that the burden of EA Debt Identification is placed onto the end users.
This indicates a dependency. The state of EA Debt diminishes directly as a conse- quence of the end users’ inability to input EA model information into the SmellCull mechanism as well as the SmellCull mechanism’s inability to enforce EA Debt gover- nance.
Automatic detection is not complete and does not have to be correct. Just because no smells were reported this does not imply a perfectly designed model. It may be the case that too few smells are automatically detectable or the used metrics or their
model are not suitable for the current environment.Also a few number of EA Smells currently detected by the SmellCull. It is a great phase of limitation.
In order to overcome the aforementioned boundary, case studies are needed to identify problems in user experience and training as well as to develop the SmellCull mechanism’s ability to be cross-compatible with other EA Debt identification and assessment tools.
Though there are some limitations in the SmellCull, this thesis provides a support to both researchers, who are interested in comprehending the results achieved so far in the identification of EA Debt, and practitioner, who are interested in adopting a tool to identify EA Debt in their Enterprise Architecture Systems.
