Embed Size (px)
Citation preview
IN DEGREE PROJECT COMPUTER SCIENCE AND ENGINEERINGSECOND CYCLE 30 CREDITS
STOCKHOLM SWEDEN 2020
Developing a Framework to measure Enterprise Architecture Debts
PARUMITA SAHA
KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE
MASTERTHESIS
SupervisorSimon Hacks
EECS KTH
Examiner Robert Lagerstrom
EECS KTH
Developing a Framework to measureEnterprise Architecture Debts
KTH Royal Institute of Technology
Parumita Saha
October 2020
Utveckling av ramverk for matning av foretagsarkitekturskuld
Parumita SahaOktober 2020
EXAMENSARBETE HandledareSimon HacksEECS KTH ExaminatorRobert Lagerstrom EECS KTH
2
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 developmentindustry technical debt is regarded as a critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability 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 thecommon bad practices that may impair the future quality of the software system Byidentifying those Code Smells it is possible to give an improved solution or make thedevelopers aware of a possible deficiency I explore the premise that technical debtwithin the enterprise should be viewed as a tool Extensible and Appropriate tools cancheck the Code Smells automatically and improve the quality assessment accordingly
However in the field of Enterprise Architecture(EA) common bad habits in EA canbe called EA Smells EA Smells itself can be a component of EA Debt EnterpriseArchitecture Debt can be defined as such a metric that depicts the deviation of thecurrently present state of an enterprise from a hypothetical ideal state
In this thesis we introduce SmellCull as an extensible tool for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model SmellCull is extensiblesince different types of Model can be integrated as input into the tool environmentand provides developers with a lightweight tool to capture EA debt and make it easierto understand them indicating corresponding parts in the implementation The toolis used to create propagation paths for the EA debt This allows for an up-to-date andaccurate presentation of EA debt to be upheld which enables developer conductedimplementation-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 thestrategic development of EAS with the corresponding roadmaps as well as design as-surance and performance monitoring to assess the quality of data in EA repositoriesand the compliance with certain standards defined by EA Smells
3
Due to the limited scope of master thesis the tool will identify a few number ofEA debt At the end some future work suggestions in the context of identifyingmore 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)
4
Sammanfattning
Teknisk skuld dvs dalig eller kortsiktig programutveckling som belastning pa IT-sys-tem maste forr eller senare aterbetalas I industrin betraktas teknisk skuld som en kritisk fraga nar det galler de negativa konsekvenserna som okad mjukvaruutveck-lingskostnad lag produktkvalitet minska underhall och langsammare framsteg till den langsiktiga framgangen med att utveckla programvara
Dalig kodkvalitet ldquocode smellrdquo ar vanligt forekommande teknisk skuld Det uppkom-mer i vanliga daliga metoder ldquoanti-patternsrdquo som forsamrar programvarans framtida kvalitet For att kunna identifiera bristande kodkvalitet ar det mojligt att skapa en forbattrad losning eller gora utvecklare medvetna om de mojliga bristerna Jag un-dersoker forutsattningarna att en sadan teknisk skuld i foretag bor undersokas med en programvara Utbyggbara och andamalsenliga programvaror kan analysera kallkod och hitta var kvaliteten behover forbattras
Foretagens tekniska skuld kan definieras som ett matt som visar avvikelsen fran ett hypotetiskt idealtillstand genom att jamfora det aktuella tillstandet med praktiska rekommendationer ldquobest practicerdquo
I detta examensarbete introducerar jag SmellCull som ett utbyggbart verktyg for att hitta spara och hantera bristfallig kodkvalitet inom foumlretagsarkitektur (EA) SmellCull tillater matning av olika typer av tekiska skulder for EA modellen SmellCull ar utbyggbart genom att olika typer av datamodeller kan integreras som indata i miljon och det ger utveck-lare ett latt verktyg for att hantera teknisk skuld i programmeringsprojekt och hjalpa projektdeltagarna i programmeringsprojekt att forsta vad orsakar brister i kodkvalitet
Eftersom verktyget ar tillrackligt sofistikerat finns det automatiserad sparning de-signprocess och kontinuerlig forbattring av EAS (Enterprise Architecture System) Detta inkluderar strategisk utveckling av EAS med motsvarande fardplan samt kon-struktionssakerhet och prestandaovervakning for att bedoma kvaliteten pa data i EA forvar och efterlevnaden av vissa standarder som definieras av EA code smell detec-tion
Pa grund av den begransade omfattningen av examensarbetet kommer verktyget att
5
identifiera nagra fa EA skuld I slutet nagra framtida arbetsforslag i samband medidentifiering mer saljbara foretagsarkitekturskulder med detta verktyg ges
Nyckelord Teknisk skuld foretagsarkitekturskuld foumlretagsarkitektur (EA) EA-verktyg
6
Acknowledgements
In the beginning I would like to thank Robert Lagerstrom for reviewing this thesisSpecial thanks go to my supervisor Simon Hacks for his input continuous feedbackand valuable suggestions during the development of this work The given critiqueshave 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 havebeen the sameFinally I thank my family friends near and dear ones for providing me with constantsupport during this thesisThank You
Parumita Saha
7
Contents
1 Introduction 1611 Motivation 1612 Goals 1713 Background 17
131 Enterprise Architecture 17132 Multilevel Modelling 19133 Technical Debt 21134 Enterprise Architecture Debt 22135 Code Smell 23
14 Research Questions 2315 Delimitations 24
2 Related Work 2621 Enterprise Architecture Model Quality Framework amp Tool 2622 Different types of Debt Management tool 27
3 Effectively utilizing Life Cycle 2931 Project life-cycle management 2932 The principle of Scrum 3333 Scrum Phase 3534 Piloting Scrum Practices 37
4 Implementations 3941 Challenges amp Requirements 3942 Structure of the SmellCull 4043 EADebt Detection using SmellCull 4244 Automation of SmellCull 4545 SmellCull Web Application 5146 Limitations 53
5 Evaluation 5551 Evaluation based on an Automatic Oracle 5552 Evaluation based on Developerrsquos Judgment 56
8
53 Evaluating the Accuracy of SmellCull Tool 5754 Demonstration on different EA Smells 58
6 Discussion 6261 Application in EA Development 6262 Benefits 63
7 Conclusion 6571 Summary 6572 Future Work 66
721 Mechanism Improvement amp Validation 66722 Extending the Range of Supported Techniques 67
A Code Smell Website 69B EA Smell Website 74
References 85
9
List of Tables
41 List of Code SmellsAntipatterns 43
10
List of Figures
11 A collaboration among Business Technology amp Operation 1812 Enterprise Architecture as a Cross-layer View of 1913 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (a) Functionality levels[27] 2014 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (b) dependency levels[27] 2015 The technical debt landscape On the left evolution or its challenges
on the right quality issues both internal and external[39] 2116 Relation Between Technical Debt amp EA Debt as a sub-domain of Tech-
nical Debt 22
31 Output with SDLC and Avoiding SDLC 3032 Scrum Process[19] 3433 Scrum Methodology 35
41 Different parts of SmellCull Architecture 4142 Sequence Diagram from High Level view 4643 Using Multilevel Modelling to create Customized Model 4744 An illustration of combining models into pojoModel 4845 Automation Process using UML Class Diagram 5046 Welcome page of Web Application 5147 Scenario after uploading the files 5248 Identification of EA Debts 53
51 EA Debt for different Domain of Model 5752 Dead Component at ldquoDeprecated Processrdquo 5953 Shared Persistency at ldquoPassenger databaserdquo 6054 Weekend Modularity at ldquoAirline administration supportrdquo 61
1 Code Smell Website page 1 of 4 692 Code Smell Website page 2 of 4 703 Code Smell Website page 3 of 4 714 Code Smell Website page 4 of 4 725 EA Smell Website page 1 of 4 74
11
6 EA Smell Website page 2 of 4 757 EA Smell Website page 3 of 4 768 EA Smell Website page 4 of 4 77
12
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
RampD Research and Development
APM Agile Project Management
EAF Enterprise Architecture Framework
EAQF Enterprise Architecture Model Quality Framework
13
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
14
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
MASTERTHESIS
SupervisorSimon Hacks
EECS KTH
Examiner Robert Lagerstrom
EECS KTH
Developing a Framework to measureEnterprise Architecture Debts
KTH Royal Institute of Technology
Parumita Saha
October 2020
Utveckling av ramverk for matning av foretagsarkitekturskuld
Parumita SahaOktober 2020
EXAMENSARBETE HandledareSimon HacksEECS KTH ExaminatorRobert Lagerstrom EECS KTH
2
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 developmentindustry technical debt is regarded as a critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability 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 thecommon bad practices that may impair the future quality of the software system Byidentifying those Code Smells it is possible to give an improved solution or make thedevelopers aware of a possible deficiency I explore the premise that technical debtwithin the enterprise should be viewed as a tool Extensible and Appropriate tools cancheck the Code Smells automatically and improve the quality assessment accordingly
However in the field of Enterprise Architecture(EA) common bad habits in EA canbe called EA Smells EA Smells itself can be a component of EA Debt EnterpriseArchitecture Debt can be defined as such a metric that depicts the deviation of thecurrently present state of an enterprise from a hypothetical ideal state
In this thesis we introduce SmellCull as an extensible tool for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model SmellCull is extensiblesince different types of Model can be integrated as input into the tool environmentand provides developers with a lightweight tool to capture EA debt and make it easierto understand them indicating corresponding parts in the implementation The toolis used to create propagation paths for the EA debt This allows for an up-to-date andaccurate presentation of EA debt to be upheld which enables developer conductedimplementation-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 thestrategic development of EAS with the corresponding roadmaps as well as design as-surance and performance monitoring to assess the quality of data in EA repositoriesand the compliance with certain standards defined by EA Smells
3
Due to the limited scope of master thesis the tool will identify a few number ofEA debt At the end some future work suggestions in the context of identifyingmore 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)
4
Sammanfattning
Teknisk skuld dvs dalig eller kortsiktig programutveckling som belastning pa IT-sys-tem maste forr eller senare aterbetalas I industrin betraktas teknisk skuld som en kritisk fraga nar det galler de negativa konsekvenserna som okad mjukvaruutveck-lingskostnad lag produktkvalitet minska underhall och langsammare framsteg till den langsiktiga framgangen med att utveckla programvara
Dalig kodkvalitet ldquocode smellrdquo ar vanligt forekommande teknisk skuld Det uppkom-mer i vanliga daliga metoder ldquoanti-patternsrdquo som forsamrar programvarans framtida kvalitet For att kunna identifiera bristande kodkvalitet ar det mojligt att skapa en forbattrad losning eller gora utvecklare medvetna om de mojliga bristerna Jag un-dersoker forutsattningarna att en sadan teknisk skuld i foretag bor undersokas med en programvara Utbyggbara och andamalsenliga programvaror kan analysera kallkod och hitta var kvaliteten behover forbattras
Foretagens tekniska skuld kan definieras som ett matt som visar avvikelsen fran ett hypotetiskt idealtillstand genom att jamfora det aktuella tillstandet med praktiska rekommendationer ldquobest practicerdquo
I detta examensarbete introducerar jag SmellCull som ett utbyggbart verktyg for att hitta spara och hantera bristfallig kodkvalitet inom foumlretagsarkitektur (EA) SmellCull tillater matning av olika typer av tekiska skulder for EA modellen SmellCull ar utbyggbart genom att olika typer av datamodeller kan integreras som indata i miljon och det ger utveck-lare ett latt verktyg for att hantera teknisk skuld i programmeringsprojekt och hjalpa projektdeltagarna i programmeringsprojekt att forsta vad orsakar brister i kodkvalitet
Eftersom verktyget ar tillrackligt sofistikerat finns det automatiserad sparning de-signprocess och kontinuerlig forbattring av EAS (Enterprise Architecture System) Detta inkluderar strategisk utveckling av EAS med motsvarande fardplan samt kon-struktionssakerhet och prestandaovervakning for att bedoma kvaliteten pa data i EA forvar och efterlevnaden av vissa standarder som definieras av EA code smell detec-tion
Pa grund av den begransade omfattningen av examensarbetet kommer verktyget att
5
identifiera nagra fa EA skuld I slutet nagra framtida arbetsforslag i samband medidentifiering mer saljbara foretagsarkitekturskulder med detta verktyg ges
Nyckelord Teknisk skuld foretagsarkitekturskuld foumlretagsarkitektur (EA) EA-verktyg
6
Acknowledgements
In the beginning I would like to thank Robert Lagerstrom for reviewing this thesisSpecial thanks go to my supervisor Simon Hacks for his input continuous feedbackand valuable suggestions during the development of this work The given critiqueshave 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 havebeen the sameFinally I thank my family friends near and dear ones for providing me with constantsupport during this thesisThank You
Parumita Saha
7
Contents
1 Introduction 1611 Motivation 1612 Goals 1713 Background 17
131 Enterprise Architecture 17132 Multilevel Modelling 19133 Technical Debt 21134 Enterprise Architecture Debt 22135 Code Smell 23
14 Research Questions 2315 Delimitations 24
2 Related Work 2621 Enterprise Architecture Model Quality Framework amp Tool 2622 Different types of Debt Management tool 27
3 Effectively utilizing Life Cycle 2931 Project life-cycle management 2932 The principle of Scrum 3333 Scrum Phase 3534 Piloting Scrum Practices 37
4 Implementations 3941 Challenges amp Requirements 3942 Structure of the SmellCull 4043 EADebt Detection using SmellCull 4244 Automation of SmellCull 4545 SmellCull Web Application 5146 Limitations 53
5 Evaluation 5551 Evaluation based on an Automatic Oracle 5552 Evaluation based on Developerrsquos Judgment 56
8
53 Evaluating the Accuracy of SmellCull Tool 5754 Demonstration on different EA Smells 58
6 Discussion 6261 Application in EA Development 6262 Benefits 63
7 Conclusion 6571 Summary 6572 Future Work 66
721 Mechanism Improvement amp Validation 66722 Extending the Range of Supported Techniques 67
A Code Smell Website 69B EA Smell Website 74
References 85
9
List of Tables
41 List of Code SmellsAntipatterns 43
10
List of Figures
11 A collaboration among Business Technology amp Operation 1812 Enterprise Architecture as a Cross-layer View of 1913 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (a) Functionality levels[27] 2014 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (b) dependency levels[27] 2015 The technical debt landscape On the left evolution or its challenges
on the right quality issues both internal and external[39] 2116 Relation Between Technical Debt amp EA Debt as a sub-domain of Tech-
nical Debt 22
31 Output with SDLC and Avoiding SDLC 3032 Scrum Process[19] 3433 Scrum Methodology 35
41 Different parts of SmellCull Architecture 4142 Sequence Diagram from High Level view 4643 Using Multilevel Modelling to create Customized Model 4744 An illustration of combining models into pojoModel 4845 Automation Process using UML Class Diagram 5046 Welcome page of Web Application 5147 Scenario after uploading the files 5248 Identification of EA Debts 53
51 EA Debt for different Domain of Model 5752 Dead Component at ldquoDeprecated Processrdquo 5953 Shared Persistency at ldquoPassenger databaserdquo 6054 Weekend Modularity at ldquoAirline administration supportrdquo 61
1 Code Smell Website page 1 of 4 692 Code Smell Website page 2 of 4 703 Code Smell Website page 3 of 4 714 Code Smell Website page 4 of 4 725 EA Smell Website page 1 of 4 74
11
6 EA Smell Website page 2 of 4 757 EA Smell Website page 3 of 4 768 EA Smell Website page 4 of 4 77
12
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
RampD Research and Development
APM Agile Project Management
EAF Enterprise Architecture Framework
EAQF Enterprise Architecture Model Quality Framework
13
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
14
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
Utveckling av ramverk for matning av foretagsarkitekturskuld
Parumita SahaOktober 2020
EXAMENSARBETE HandledareSimon HacksEECS KTH ExaminatorRobert Lagerstrom EECS KTH
2
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 developmentindustry technical debt is regarded as a critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability 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 thecommon bad practices that may impair the future quality of the software system Byidentifying those Code Smells it is possible to give an improved solution or make thedevelopers aware of a possible deficiency I explore the premise that technical debtwithin the enterprise should be viewed as a tool Extensible and Appropriate tools cancheck the Code Smells automatically and improve the quality assessment accordingly
However in the field of Enterprise Architecture(EA) common bad habits in EA canbe called EA Smells EA Smells itself can be a component of EA Debt EnterpriseArchitecture Debt can be defined as such a metric that depicts the deviation of thecurrently present state of an enterprise from a hypothetical ideal state
In this thesis we introduce SmellCull as an extensible tool for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model SmellCull is extensiblesince different types of Model can be integrated as input into the tool environmentand provides developers with a lightweight tool to capture EA debt and make it easierto understand them indicating corresponding parts in the implementation The toolis used to create propagation paths for the EA debt This allows for an up-to-date andaccurate presentation of EA debt to be upheld which enables developer conductedimplementation-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 thestrategic development of EAS with the corresponding roadmaps as well as design as-surance and performance monitoring to assess the quality of data in EA repositoriesand the compliance with certain standards defined by EA Smells
3
Due to the limited scope of master thesis the tool will identify a few number ofEA debt At the end some future work suggestions in the context of identifyingmore 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)
4
Sammanfattning
Teknisk skuld dvs dalig eller kortsiktig programutveckling som belastning pa IT-sys-tem maste forr eller senare aterbetalas I industrin betraktas teknisk skuld som en kritisk fraga nar det galler de negativa konsekvenserna som okad mjukvaruutveck-lingskostnad lag produktkvalitet minska underhall och langsammare framsteg till den langsiktiga framgangen med att utveckla programvara
Dalig kodkvalitet ldquocode smellrdquo ar vanligt forekommande teknisk skuld Det uppkom-mer i vanliga daliga metoder ldquoanti-patternsrdquo som forsamrar programvarans framtida kvalitet For att kunna identifiera bristande kodkvalitet ar det mojligt att skapa en forbattrad losning eller gora utvecklare medvetna om de mojliga bristerna Jag un-dersoker forutsattningarna att en sadan teknisk skuld i foretag bor undersokas med en programvara Utbyggbara och andamalsenliga programvaror kan analysera kallkod och hitta var kvaliteten behover forbattras
Foretagens tekniska skuld kan definieras som ett matt som visar avvikelsen fran ett hypotetiskt idealtillstand genom att jamfora det aktuella tillstandet med praktiska rekommendationer ldquobest practicerdquo
I detta examensarbete introducerar jag SmellCull som ett utbyggbart verktyg for att hitta spara och hantera bristfallig kodkvalitet inom foumlretagsarkitektur (EA) SmellCull tillater matning av olika typer av tekiska skulder for EA modellen SmellCull ar utbyggbart genom att olika typer av datamodeller kan integreras som indata i miljon och det ger utveck-lare ett latt verktyg for att hantera teknisk skuld i programmeringsprojekt och hjalpa projektdeltagarna i programmeringsprojekt att forsta vad orsakar brister i kodkvalitet
Eftersom verktyget ar tillrackligt sofistikerat finns det automatiserad sparning de-signprocess och kontinuerlig forbattring av EAS (Enterprise Architecture System) Detta inkluderar strategisk utveckling av EAS med motsvarande fardplan samt kon-struktionssakerhet och prestandaovervakning for att bedoma kvaliteten pa data i EA forvar och efterlevnaden av vissa standarder som definieras av EA code smell detec-tion
Pa grund av den begransade omfattningen av examensarbetet kommer verktyget att
5
identifiera nagra fa EA skuld I slutet nagra framtida arbetsforslag i samband medidentifiering mer saljbara foretagsarkitekturskulder med detta verktyg ges
Nyckelord Teknisk skuld foretagsarkitekturskuld foumlretagsarkitektur (EA) EA-verktyg
6
Acknowledgements
In the beginning I would like to thank Robert Lagerstrom for reviewing this thesisSpecial thanks go to my supervisor Simon Hacks for his input continuous feedbackand valuable suggestions during the development of this work The given critiqueshave 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 havebeen the sameFinally I thank my family friends near and dear ones for providing me with constantsupport during this thesisThank You
Parumita Saha
7
Contents
1 Introduction 1611 Motivation 1612 Goals 1713 Background 17
131 Enterprise Architecture 17132 Multilevel Modelling 19133 Technical Debt 21134 Enterprise Architecture Debt 22135 Code Smell 23
14 Research Questions 2315 Delimitations 24
2 Related Work 2621 Enterprise Architecture Model Quality Framework amp Tool 2622 Different types of Debt Management tool 27
3 Effectively utilizing Life Cycle 2931 Project life-cycle management 2932 The principle of Scrum 3333 Scrum Phase 3534 Piloting Scrum Practices 37
4 Implementations 3941 Challenges amp Requirements 3942 Structure of the SmellCull 4043 EADebt Detection using SmellCull 4244 Automation of SmellCull 4545 SmellCull Web Application 5146 Limitations 53
5 Evaluation 5551 Evaluation based on an Automatic Oracle 5552 Evaluation based on Developerrsquos Judgment 56
8
53 Evaluating the Accuracy of SmellCull Tool 5754 Demonstration on different EA Smells 58
6 Discussion 6261 Application in EA Development 6262 Benefits 63
7 Conclusion 6571 Summary 6572 Future Work 66
721 Mechanism Improvement amp Validation 66722 Extending the Range of Supported Techniques 67
A Code Smell Website 69B EA Smell Website 74
References 85
9
List of Tables
41 List of Code SmellsAntipatterns 43
10
List of Figures
11 A collaboration among Business Technology amp Operation 1812 Enterprise Architecture as a Cross-layer View of 1913 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (a) Functionality levels[27] 2014 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (b) dependency levels[27] 2015 The technical debt landscape On the left evolution or its challenges
on the right quality issues both internal and external[39] 2116 Relation Between Technical Debt amp EA Debt as a sub-domain of Tech-
nical Debt 22
31 Output with SDLC and Avoiding SDLC 3032 Scrum Process[19] 3433 Scrum Methodology 35
41 Different parts of SmellCull Architecture 4142 Sequence Diagram from High Level view 4643 Using Multilevel Modelling to create Customized Model 4744 An illustration of combining models into pojoModel 4845 Automation Process using UML Class Diagram 5046 Welcome page of Web Application 5147 Scenario after uploading the files 5248 Identification of EA Debts 53
51 EA Debt for different Domain of Model 5752 Dead Component at ldquoDeprecated Processrdquo 5953 Shared Persistency at ldquoPassenger databaserdquo 6054 Weekend Modularity at ldquoAirline administration supportrdquo 61
1 Code Smell Website page 1 of 4 692 Code Smell Website page 2 of 4 703 Code Smell Website page 3 of 4 714 Code Smell Website page 4 of 4 725 EA Smell Website page 1 of 4 74
11
6 EA Smell Website page 2 of 4 757 EA Smell Website page 3 of 4 768 EA Smell Website page 4 of 4 77
12
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
RampD Research and Development
APM Agile Project Management
EAF Enterprise Architecture Framework
EAQF Enterprise Architecture Model Quality Framework
13
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
14
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
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 developmentindustry technical debt is regarded as a critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability 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 thecommon bad practices that may impair the future quality of the software system Byidentifying those Code Smells it is possible to give an improved solution or make thedevelopers aware of a possible deficiency I explore the premise that technical debtwithin the enterprise should be viewed as a tool Extensible and Appropriate tools cancheck the Code Smells automatically and improve the quality assessment accordingly
However in the field of Enterprise Architecture(EA) common bad habits in EA canbe called EA Smells EA Smells itself can be a component of EA Debt EnterpriseArchitecture Debt can be defined as such a metric that depicts the deviation of thecurrently present state of an enterprise from a hypothetical ideal state
In this thesis we introduce SmellCull as an extensible tool for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model SmellCull is extensiblesince different types of Model can be integrated as input into the tool environmentand provides developers with a lightweight tool to capture EA debt and make it easierto understand them indicating corresponding parts in the implementation The toolis used to create propagation paths for the EA debt This allows for an up-to-date andaccurate presentation of EA debt to be upheld which enables developer conductedimplementation-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 thestrategic development of EAS with the corresponding roadmaps as well as design as-surance and performance monitoring to assess the quality of data in EA repositoriesand the compliance with certain standards defined by EA Smells
3
Due to the limited scope of master thesis the tool will identify a few number ofEA debt At the end some future work suggestions in the context of identifyingmore 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)
4
Sammanfattning
Teknisk skuld dvs dalig eller kortsiktig programutveckling som belastning pa IT-sys-tem maste forr eller senare aterbetalas I industrin betraktas teknisk skuld som en kritisk fraga nar det galler de negativa konsekvenserna som okad mjukvaruutveck-lingskostnad lag produktkvalitet minska underhall och langsammare framsteg till den langsiktiga framgangen med att utveckla programvara
Dalig kodkvalitet ldquocode smellrdquo ar vanligt forekommande teknisk skuld Det uppkom-mer i vanliga daliga metoder ldquoanti-patternsrdquo som forsamrar programvarans framtida kvalitet For att kunna identifiera bristande kodkvalitet ar det mojligt att skapa en forbattrad losning eller gora utvecklare medvetna om de mojliga bristerna Jag un-dersoker forutsattningarna att en sadan teknisk skuld i foretag bor undersokas med en programvara Utbyggbara och andamalsenliga programvaror kan analysera kallkod och hitta var kvaliteten behover forbattras
Foretagens tekniska skuld kan definieras som ett matt som visar avvikelsen fran ett hypotetiskt idealtillstand genom att jamfora det aktuella tillstandet med praktiska rekommendationer ldquobest practicerdquo
I detta examensarbete introducerar jag SmellCull som ett utbyggbart verktyg for att hitta spara och hantera bristfallig kodkvalitet inom foumlretagsarkitektur (EA) SmellCull tillater matning av olika typer av tekiska skulder for EA modellen SmellCull ar utbyggbart genom att olika typer av datamodeller kan integreras som indata i miljon och det ger utveck-lare ett latt verktyg for att hantera teknisk skuld i programmeringsprojekt och hjalpa projektdeltagarna i programmeringsprojekt att forsta vad orsakar brister i kodkvalitet
Eftersom verktyget ar tillrackligt sofistikerat finns det automatiserad sparning de-signprocess och kontinuerlig forbattring av EAS (Enterprise Architecture System) Detta inkluderar strategisk utveckling av EAS med motsvarande fardplan samt kon-struktionssakerhet och prestandaovervakning for att bedoma kvaliteten pa data i EA forvar och efterlevnaden av vissa standarder som definieras av EA code smell detec-tion
Pa grund av den begransade omfattningen av examensarbetet kommer verktyget att
5
identifiera nagra fa EA skuld I slutet nagra framtida arbetsforslag i samband medidentifiering mer saljbara foretagsarkitekturskulder med detta verktyg ges
Nyckelord Teknisk skuld foretagsarkitekturskuld foumlretagsarkitektur (EA) EA-verktyg
6
Acknowledgements
In the beginning I would like to thank Robert Lagerstrom for reviewing this thesisSpecial thanks go to my supervisor Simon Hacks for his input continuous feedbackand valuable suggestions during the development of this work The given critiqueshave 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 havebeen the sameFinally I thank my family friends near and dear ones for providing me with constantsupport during this thesisThank You
Parumita Saha
7
Contents
1 Introduction 1611 Motivation 1612 Goals 1713 Background 17
131 Enterprise Architecture 17132 Multilevel Modelling 19133 Technical Debt 21134 Enterprise Architecture Debt 22135 Code Smell 23
14 Research Questions 2315 Delimitations 24
2 Related Work 2621 Enterprise Architecture Model Quality Framework amp Tool 2622 Different types of Debt Management tool 27
3 Effectively utilizing Life Cycle 2931 Project life-cycle management 2932 The principle of Scrum 3333 Scrum Phase 3534 Piloting Scrum Practices 37
4 Implementations 3941 Challenges amp Requirements 3942 Structure of the SmellCull 4043 EADebt Detection using SmellCull 4244 Automation of SmellCull 4545 SmellCull Web Application 5146 Limitations 53
5 Evaluation 5551 Evaluation based on an Automatic Oracle 5552 Evaluation based on Developerrsquos Judgment 56
8
53 Evaluating the Accuracy of SmellCull Tool 5754 Demonstration on different EA Smells 58
6 Discussion 6261 Application in EA Development 6262 Benefits 63
7 Conclusion 6571 Summary 6572 Future Work 66
721 Mechanism Improvement amp Validation 66722 Extending the Range of Supported Techniques 67
A Code Smell Website 69B EA Smell Website 74
References 85
9
List of Tables
41 List of Code SmellsAntipatterns 43
10
List of Figures
11 A collaboration among Business Technology amp Operation 1812 Enterprise Architecture as a Cross-layer View of 1913 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (a) Functionality levels[27] 2014 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (b) dependency levels[27] 2015 The technical debt landscape On the left evolution or its challenges
on the right quality issues both internal and external[39] 2116 Relation Between Technical Debt amp EA Debt as a sub-domain of Tech-
nical Debt 22
31 Output with SDLC and Avoiding SDLC 3032 Scrum Process[19] 3433 Scrum Methodology 35
41 Different parts of SmellCull Architecture 4142 Sequence Diagram from High Level view 4643 Using Multilevel Modelling to create Customized Model 4744 An illustration of combining models into pojoModel 4845 Automation Process using UML Class Diagram 5046 Welcome page of Web Application 5147 Scenario after uploading the files 5248 Identification of EA Debts 53
51 EA Debt for different Domain of Model 5752 Dead Component at ldquoDeprecated Processrdquo 5953 Shared Persistency at ldquoPassenger databaserdquo 6054 Weekend Modularity at ldquoAirline administration supportrdquo 61
1 Code Smell Website page 1 of 4 692 Code Smell Website page 2 of 4 703 Code Smell Website page 3 of 4 714 Code Smell Website page 4 of 4 725 EA Smell Website page 1 of 4 74
11
6 EA Smell Website page 2 of 4 757 EA Smell Website page 3 of 4 768 EA Smell Website page 4 of 4 77
12
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
RampD Research and Development
APM Agile Project Management
EAF Enterprise Architecture Framework
EAQF Enterprise Architecture Model Quality Framework
13
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
14
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
Due to the limited scope of master thesis the tool will identify a few number ofEA debt At the end some future work suggestions in the context of identifyingmore 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)
4
Sammanfattning
Teknisk skuld dvs dalig eller kortsiktig programutveckling som belastning pa IT-sys-tem maste forr eller senare aterbetalas I industrin betraktas teknisk skuld som en kritisk fraga nar det galler de negativa konsekvenserna som okad mjukvaruutveck-lingskostnad lag produktkvalitet minska underhall och langsammare framsteg till den langsiktiga framgangen med att utveckla programvara
Dalig kodkvalitet ldquocode smellrdquo ar vanligt forekommande teknisk skuld Det uppkom-mer i vanliga daliga metoder ldquoanti-patternsrdquo som forsamrar programvarans framtida kvalitet For att kunna identifiera bristande kodkvalitet ar det mojligt att skapa en forbattrad losning eller gora utvecklare medvetna om de mojliga bristerna Jag un-dersoker forutsattningarna att en sadan teknisk skuld i foretag bor undersokas med en programvara Utbyggbara och andamalsenliga programvaror kan analysera kallkod och hitta var kvaliteten behover forbattras
Foretagens tekniska skuld kan definieras som ett matt som visar avvikelsen fran ett hypotetiskt idealtillstand genom att jamfora det aktuella tillstandet med praktiska rekommendationer ldquobest practicerdquo
I detta examensarbete introducerar jag SmellCull som ett utbyggbart verktyg for att hitta spara och hantera bristfallig kodkvalitet inom foumlretagsarkitektur (EA) SmellCull tillater matning av olika typer av tekiska skulder for EA modellen SmellCull ar utbyggbart genom att olika typer av datamodeller kan integreras som indata i miljon och det ger utveck-lare ett latt verktyg for att hantera teknisk skuld i programmeringsprojekt och hjalpa projektdeltagarna i programmeringsprojekt att forsta vad orsakar brister i kodkvalitet
Eftersom verktyget ar tillrackligt sofistikerat finns det automatiserad sparning de-signprocess och kontinuerlig forbattring av EAS (Enterprise Architecture System) Detta inkluderar strategisk utveckling av EAS med motsvarande fardplan samt kon-struktionssakerhet och prestandaovervakning for att bedoma kvaliteten pa data i EA forvar och efterlevnaden av vissa standarder som definieras av EA code smell detec-tion
Pa grund av den begransade omfattningen av examensarbetet kommer verktyget att
5
identifiera nagra fa EA skuld I slutet nagra framtida arbetsforslag i samband medidentifiering mer saljbara foretagsarkitekturskulder med detta verktyg ges
Nyckelord Teknisk skuld foretagsarkitekturskuld foumlretagsarkitektur (EA) EA-verktyg
6
Acknowledgements
In the beginning I would like to thank Robert Lagerstrom for reviewing this thesisSpecial thanks go to my supervisor Simon Hacks for his input continuous feedbackand valuable suggestions during the development of this work The given critiqueshave 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 havebeen the sameFinally I thank my family friends near and dear ones for providing me with constantsupport during this thesisThank You
Parumita Saha
7
Contents
1 Introduction 1611 Motivation 1612 Goals 1713 Background 17
131 Enterprise Architecture 17132 Multilevel Modelling 19133 Technical Debt 21134 Enterprise Architecture Debt 22135 Code Smell 23
14 Research Questions 2315 Delimitations 24
2 Related Work 2621 Enterprise Architecture Model Quality Framework amp Tool 2622 Different types of Debt Management tool 27
3 Effectively utilizing Life Cycle 2931 Project life-cycle management 2932 The principle of Scrum 3333 Scrum Phase 3534 Piloting Scrum Practices 37
4 Implementations 3941 Challenges amp Requirements 3942 Structure of the SmellCull 4043 EADebt Detection using SmellCull 4244 Automation of SmellCull 4545 SmellCull Web Application 5146 Limitations 53
5 Evaluation 5551 Evaluation based on an Automatic Oracle 5552 Evaluation based on Developerrsquos Judgment 56
8
53 Evaluating the Accuracy of SmellCull Tool 5754 Demonstration on different EA Smells 58
6 Discussion 6261 Application in EA Development 6262 Benefits 63
7 Conclusion 6571 Summary 6572 Future Work 66
721 Mechanism Improvement amp Validation 66722 Extending the Range of Supported Techniques 67
A Code Smell Website 69B EA Smell Website 74
References 85
9
List of Tables
41 List of Code SmellsAntipatterns 43
10
List of Figures
11 A collaboration among Business Technology amp Operation 1812 Enterprise Architecture as a Cross-layer View of 1913 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (a) Functionality levels[27] 2014 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (b) dependency levels[27] 2015 The technical debt landscape On the left evolution or its challenges
on the right quality issues both internal and external[39] 2116 Relation Between Technical Debt amp EA Debt as a sub-domain of Tech-
nical Debt 22
31 Output with SDLC and Avoiding SDLC 3032 Scrum Process[19] 3433 Scrum Methodology 35
41 Different parts of SmellCull Architecture 4142 Sequence Diagram from High Level view 4643 Using Multilevel Modelling to create Customized Model 4744 An illustration of combining models into pojoModel 4845 Automation Process using UML Class Diagram 5046 Welcome page of Web Application 5147 Scenario after uploading the files 5248 Identification of EA Debts 53
51 EA Debt for different Domain of Model 5752 Dead Component at ldquoDeprecated Processrdquo 5953 Shared Persistency at ldquoPassenger databaserdquo 6054 Weekend Modularity at ldquoAirline administration supportrdquo 61
1 Code Smell Website page 1 of 4 692 Code Smell Website page 2 of 4 703 Code Smell Website page 3 of 4 714 Code Smell Website page 4 of 4 725 EA Smell Website page 1 of 4 74
11
6 EA Smell Website page 2 of 4 757 EA Smell Website page 3 of 4 768 EA Smell Website page 4 of 4 77
12
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
RampD Research and Development
APM Agile Project Management
EAF Enterprise Architecture Framework
EAQF Enterprise Architecture Model Quality Framework
13
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
14
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
Sammanfattning
Teknisk skuld dvs dalig eller kortsiktig programutveckling som belastning pa IT-sys-tem maste forr eller senare aterbetalas I industrin betraktas teknisk skuld som en kritisk fraga nar det galler de negativa konsekvenserna som okad mjukvaruutveck-lingskostnad lag produktkvalitet minska underhall och langsammare framsteg till den langsiktiga framgangen med att utveckla programvara
Dalig kodkvalitet ldquocode smellrdquo ar vanligt forekommande teknisk skuld Det uppkom-mer i vanliga daliga metoder ldquoanti-patternsrdquo som forsamrar programvarans framtida kvalitet For att kunna identifiera bristande kodkvalitet ar det mojligt att skapa en forbattrad losning eller gora utvecklare medvetna om de mojliga bristerna Jag un-dersoker forutsattningarna att en sadan teknisk skuld i foretag bor undersokas med en programvara Utbyggbara och andamalsenliga programvaror kan analysera kallkod och hitta var kvaliteten behover forbattras
Foretagens tekniska skuld kan definieras som ett matt som visar avvikelsen fran ett hypotetiskt idealtillstand genom att jamfora det aktuella tillstandet med praktiska rekommendationer ldquobest practicerdquo
I detta examensarbete introducerar jag SmellCull som ett utbyggbart verktyg for att hitta spara och hantera bristfallig kodkvalitet inom foumlretagsarkitektur (EA) SmellCull tillater matning av olika typer av tekiska skulder for EA modellen SmellCull ar utbyggbart genom att olika typer av datamodeller kan integreras som indata i miljon och det ger utveck-lare ett latt verktyg for att hantera teknisk skuld i programmeringsprojekt och hjalpa projektdeltagarna i programmeringsprojekt att forsta vad orsakar brister i kodkvalitet
Eftersom verktyget ar tillrackligt sofistikerat finns det automatiserad sparning de-signprocess och kontinuerlig forbattring av EAS (Enterprise Architecture System) Detta inkluderar strategisk utveckling av EAS med motsvarande fardplan samt kon-struktionssakerhet och prestandaovervakning for att bedoma kvaliteten pa data i EA forvar och efterlevnaden av vissa standarder som definieras av EA code smell detec-tion
Pa grund av den begransade omfattningen av examensarbetet kommer verktyget att
5
identifiera nagra fa EA skuld I slutet nagra framtida arbetsforslag i samband medidentifiering mer saljbara foretagsarkitekturskulder med detta verktyg ges
Nyckelord Teknisk skuld foretagsarkitekturskuld foumlretagsarkitektur (EA) EA-verktyg
6
Acknowledgements
In the beginning I would like to thank Robert Lagerstrom for reviewing this thesisSpecial thanks go to my supervisor Simon Hacks for his input continuous feedbackand valuable suggestions during the development of this work The given critiqueshave 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 havebeen the sameFinally I thank my family friends near and dear ones for providing me with constantsupport during this thesisThank You
Parumita Saha
7
Contents
1 Introduction 1611 Motivation 1612 Goals 1713 Background 17
131 Enterprise Architecture 17132 Multilevel Modelling 19133 Technical Debt 21134 Enterprise Architecture Debt 22135 Code Smell 23
14 Research Questions 2315 Delimitations 24
2 Related Work 2621 Enterprise Architecture Model Quality Framework amp Tool 2622 Different types of Debt Management tool 27
3 Effectively utilizing Life Cycle 2931 Project life-cycle management 2932 The principle of Scrum 3333 Scrum Phase 3534 Piloting Scrum Practices 37
4 Implementations 3941 Challenges amp Requirements 3942 Structure of the SmellCull 4043 EADebt Detection using SmellCull 4244 Automation of SmellCull 4545 SmellCull Web Application 5146 Limitations 53
5 Evaluation 5551 Evaluation based on an Automatic Oracle 5552 Evaluation based on Developerrsquos Judgment 56
8
53 Evaluating the Accuracy of SmellCull Tool 5754 Demonstration on different EA Smells 58
6 Discussion 6261 Application in EA Development 6262 Benefits 63
7 Conclusion 6571 Summary 6572 Future Work 66
721 Mechanism Improvement amp Validation 66722 Extending the Range of Supported Techniques 67
A Code Smell Website 69B EA Smell Website 74
References 85
9
List of Tables
41 List of Code SmellsAntipatterns 43
10
List of Figures
11 A collaboration among Business Technology amp Operation 1812 Enterprise Architecture as a Cross-layer View of 1913 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (a) Functionality levels[27] 2014 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (b) dependency levels[27] 2015 The technical debt landscape On the left evolution or its challenges
on the right quality issues both internal and external[39] 2116 Relation Between Technical Debt amp EA Debt as a sub-domain of Tech-
nical Debt 22
31 Output with SDLC and Avoiding SDLC 3032 Scrum Process[19] 3433 Scrum Methodology 35
41 Different parts of SmellCull Architecture 4142 Sequence Diagram from High Level view 4643 Using Multilevel Modelling to create Customized Model 4744 An illustration of combining models into pojoModel 4845 Automation Process using UML Class Diagram 5046 Welcome page of Web Application 5147 Scenario after uploading the files 5248 Identification of EA Debts 53
51 EA Debt for different Domain of Model 5752 Dead Component at ldquoDeprecated Processrdquo 5953 Shared Persistency at ldquoPassenger databaserdquo 6054 Weekend Modularity at ldquoAirline administration supportrdquo 61
1 Code Smell Website page 1 of 4 692 Code Smell Website page 2 of 4 703 Code Smell Website page 3 of 4 714 Code Smell Website page 4 of 4 725 EA Smell Website page 1 of 4 74
11
6 EA Smell Website page 2 of 4 757 EA Smell Website page 3 of 4 768 EA Smell Website page 4 of 4 77
12
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
RampD Research and Development
APM Agile Project Management
EAF Enterprise Architecture Framework
EAQF Enterprise Architecture Model Quality Framework
13
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
14
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
identifiera nagra fa EA skuld I slutet nagra framtida arbetsforslag i samband medidentifiering mer saljbara foretagsarkitekturskulder med detta verktyg ges
Nyckelord Teknisk skuld foretagsarkitekturskuld foumlretagsarkitektur (EA) EA-verktyg
6
Acknowledgements
In the beginning I would like to thank Robert Lagerstrom for reviewing this thesisSpecial thanks go to my supervisor Simon Hacks for his input continuous feedbackand valuable suggestions during the development of this work The given critiqueshave 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 havebeen the sameFinally I thank my family friends near and dear ones for providing me with constantsupport during this thesisThank You
Parumita Saha
7
Contents
1 Introduction 1611 Motivation 1612 Goals 1713 Background 17
131 Enterprise Architecture 17132 Multilevel Modelling 19133 Technical Debt 21134 Enterprise Architecture Debt 22135 Code Smell 23
14 Research Questions 2315 Delimitations 24
2 Related Work 2621 Enterprise Architecture Model Quality Framework amp Tool 2622 Different types of Debt Management tool 27
3 Effectively utilizing Life Cycle 2931 Project life-cycle management 2932 The principle of Scrum 3333 Scrum Phase 3534 Piloting Scrum Practices 37
4 Implementations 3941 Challenges amp Requirements 3942 Structure of the SmellCull 4043 EADebt Detection using SmellCull 4244 Automation of SmellCull 4545 SmellCull Web Application 5146 Limitations 53
5 Evaluation 5551 Evaluation based on an Automatic Oracle 5552 Evaluation based on Developerrsquos Judgment 56
8
53 Evaluating the Accuracy of SmellCull Tool 5754 Demonstration on different EA Smells 58
6 Discussion 6261 Application in EA Development 6262 Benefits 63
7 Conclusion 6571 Summary 6572 Future Work 66
721 Mechanism Improvement amp Validation 66722 Extending the Range of Supported Techniques 67
A Code Smell Website 69B EA Smell Website 74
References 85
9
List of Tables
41 List of Code SmellsAntipatterns 43
10
List of Figures
11 A collaboration among Business Technology amp Operation 1812 Enterprise Architecture as a Cross-layer View of 1913 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (a) Functionality levels[27] 2014 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (b) dependency levels[27] 2015 The technical debt landscape On the left evolution or its challenges
on the right quality issues both internal and external[39] 2116 Relation Between Technical Debt amp EA Debt as a sub-domain of Tech-
nical Debt 22
31 Output with SDLC and Avoiding SDLC 3032 Scrum Process[19] 3433 Scrum Methodology 35
41 Different parts of SmellCull Architecture 4142 Sequence Diagram from High Level view 4643 Using Multilevel Modelling to create Customized Model 4744 An illustration of combining models into pojoModel 4845 Automation Process using UML Class Diagram 5046 Welcome page of Web Application 5147 Scenario after uploading the files 5248 Identification of EA Debts 53
51 EA Debt for different Domain of Model 5752 Dead Component at ldquoDeprecated Processrdquo 5953 Shared Persistency at ldquoPassenger databaserdquo 6054 Weekend Modularity at ldquoAirline administration supportrdquo 61
1 Code Smell Website page 1 of 4 692 Code Smell Website page 2 of 4 703 Code Smell Website page 3 of 4 714 Code Smell Website page 4 of 4 725 EA Smell Website page 1 of 4 74
11
6 EA Smell Website page 2 of 4 757 EA Smell Website page 3 of 4 768 EA Smell Website page 4 of 4 77
12
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
RampD Research and Development
APM Agile Project Management
EAF Enterprise Architecture Framework
EAQF Enterprise Architecture Model Quality Framework
13
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
14
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
Acknowledgements
In the beginning I would like to thank Robert Lagerstrom for reviewing this thesisSpecial thanks go to my supervisor Simon Hacks for his input continuous feedbackand valuable suggestions during the development of this work The given critiqueshave 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 havebeen the sameFinally I thank my family friends near and dear ones for providing me with constantsupport during this thesisThank You
Parumita Saha
7
Contents
1 Introduction 1611 Motivation 1612 Goals 1713 Background 17
131 Enterprise Architecture 17132 Multilevel Modelling 19133 Technical Debt 21134 Enterprise Architecture Debt 22135 Code Smell 23
14 Research Questions 2315 Delimitations 24
2 Related Work 2621 Enterprise Architecture Model Quality Framework amp Tool 2622 Different types of Debt Management tool 27
3 Effectively utilizing Life Cycle 2931 Project life-cycle management 2932 The principle of Scrum 3333 Scrum Phase 3534 Piloting Scrum Practices 37
4 Implementations 3941 Challenges amp Requirements 3942 Structure of the SmellCull 4043 EADebt Detection using SmellCull 4244 Automation of SmellCull 4545 SmellCull Web Application 5146 Limitations 53
5 Evaluation 5551 Evaluation based on an Automatic Oracle 5552 Evaluation based on Developerrsquos Judgment 56
8
53 Evaluating the Accuracy of SmellCull Tool 5754 Demonstration on different EA Smells 58
6 Discussion 6261 Application in EA Development 6262 Benefits 63
7 Conclusion 6571 Summary 6572 Future Work 66
721 Mechanism Improvement amp Validation 66722 Extending the Range of Supported Techniques 67
A Code Smell Website 69B EA Smell Website 74
References 85
9
List of Tables
41 List of Code SmellsAntipatterns 43
10
List of Figures
11 A collaboration among Business Technology amp Operation 1812 Enterprise Architecture as a Cross-layer View of 1913 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (a) Functionality levels[27] 2014 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (b) dependency levels[27] 2015 The technical debt landscape On the left evolution or its challenges
on the right quality issues both internal and external[39] 2116 Relation Between Technical Debt amp EA Debt as a sub-domain of Tech-
nical Debt 22
31 Output with SDLC and Avoiding SDLC 3032 Scrum Process[19] 3433 Scrum Methodology 35
41 Different parts of SmellCull Architecture 4142 Sequence Diagram from High Level view 4643 Using Multilevel Modelling to create Customized Model 4744 An illustration of combining models into pojoModel 4845 Automation Process using UML Class Diagram 5046 Welcome page of Web Application 5147 Scenario after uploading the files 5248 Identification of EA Debts 53
51 EA Debt for different Domain of Model 5752 Dead Component at ldquoDeprecated Processrdquo 5953 Shared Persistency at ldquoPassenger databaserdquo 6054 Weekend Modularity at ldquoAirline administration supportrdquo 61
1 Code Smell Website page 1 of 4 692 Code Smell Website page 2 of 4 703 Code Smell Website page 3 of 4 714 Code Smell Website page 4 of 4 725 EA Smell Website page 1 of 4 74
11
6 EA Smell Website page 2 of 4 757 EA Smell Website page 3 of 4 768 EA Smell Website page 4 of 4 77
12
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
RampD Research and Development
APM Agile Project Management
EAF Enterprise Architecture Framework
EAQF Enterprise Architecture Model Quality Framework
13
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
14
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
Contents
1 Introduction 1611 Motivation 1612 Goals 1713 Background 17
131 Enterprise Architecture 17132 Multilevel Modelling 19133 Technical Debt 21134 Enterprise Architecture Debt 22135 Code Smell 23
14 Research Questions 2315 Delimitations 24
2 Related Work 2621 Enterprise Architecture Model Quality Framework amp Tool 2622 Different types of Debt Management tool 27
3 Effectively utilizing Life Cycle 2931 Project life-cycle management 2932 The principle of Scrum 3333 Scrum Phase 3534 Piloting Scrum Practices 37
4 Implementations 3941 Challenges amp Requirements 3942 Structure of the SmellCull 4043 EADebt Detection using SmellCull 4244 Automation of SmellCull 4545 SmellCull Web Application 5146 Limitations 53
5 Evaluation 5551 Evaluation based on an Automatic Oracle 5552 Evaluation based on Developerrsquos Judgment 56
8
53 Evaluating the Accuracy of SmellCull Tool 5754 Demonstration on different EA Smells 58
6 Discussion 6261 Application in EA Development 6262 Benefits 63
7 Conclusion 6571 Summary 6572 Future Work 66
721 Mechanism Improvement amp Validation 66722 Extending the Range of Supported Techniques 67
A Code Smell Website 69B EA Smell Website 74
References 85
9
List of Tables
41 List of Code SmellsAntipatterns 43
10
List of Figures
11 A collaboration among Business Technology amp Operation 1812 Enterprise Architecture as a Cross-layer View of 1913 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (a) Functionality levels[27] 2014 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (b) dependency levels[27] 2015 The technical debt landscape On the left evolution or its challenges
on the right quality issues both internal and external[39] 2116 Relation Between Technical Debt amp EA Debt as a sub-domain of Tech-
nical Debt 22
31 Output with SDLC and Avoiding SDLC 3032 Scrum Process[19] 3433 Scrum Methodology 35
41 Different parts of SmellCull Architecture 4142 Sequence Diagram from High Level view 4643 Using Multilevel Modelling to create Customized Model 4744 An illustration of combining models into pojoModel 4845 Automation Process using UML Class Diagram 5046 Welcome page of Web Application 5147 Scenario after uploading the files 5248 Identification of EA Debts 53
51 EA Debt for different Domain of Model 5752 Dead Component at ldquoDeprecated Processrdquo 5953 Shared Persistency at ldquoPassenger databaserdquo 6054 Weekend Modularity at ldquoAirline administration supportrdquo 61
1 Code Smell Website page 1 of 4 692 Code Smell Website page 2 of 4 703 Code Smell Website page 3 of 4 714 Code Smell Website page 4 of 4 725 EA Smell Website page 1 of 4 74
11
6 EA Smell Website page 2 of 4 757 EA Smell Website page 3 of 4 768 EA Smell Website page 4 of 4 77
12
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
RampD Research and Development
APM Agile Project Management
EAF Enterprise Architecture Framework
EAQF Enterprise Architecture Model Quality Framework
13
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
14
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
53 Evaluating the Accuracy of SmellCull Tool 5754 Demonstration on different EA Smells 58
6 Discussion 6261 Application in EA Development 6262 Benefits 63
7 Conclusion 6571 Summary 6572 Future Work 66
721 Mechanism Improvement amp Validation 66722 Extending the Range of Supported Techniques 67
A Code Smell Website 69B EA Smell Website 74
References 85
9
List of Tables
41 List of Code SmellsAntipatterns 43
10
List of Figures
11 A collaboration among Business Technology amp Operation 1812 Enterprise Architecture as a Cross-layer View of 1913 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (a) Functionality levels[27] 2014 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (b) dependency levels[27] 2015 The technical debt landscape On the left evolution or its challenges
on the right quality issues both internal and external[39] 2116 Relation Between Technical Debt amp EA Debt as a sub-domain of Tech-
nical Debt 22
31 Output with SDLC and Avoiding SDLC 3032 Scrum Process[19] 3433 Scrum Methodology 35
41 Different parts of SmellCull Architecture 4142 Sequence Diagram from High Level view 4643 Using Multilevel Modelling to create Customized Model 4744 An illustration of combining models into pojoModel 4845 Automation Process using UML Class Diagram 5046 Welcome page of Web Application 5147 Scenario after uploading the files 5248 Identification of EA Debts 53
51 EA Debt for different Domain of Model 5752 Dead Component at ldquoDeprecated Processrdquo 5953 Shared Persistency at ldquoPassenger databaserdquo 6054 Weekend Modularity at ldquoAirline administration supportrdquo 61
1 Code Smell Website page 1 of 4 692 Code Smell Website page 2 of 4 703 Code Smell Website page 3 of 4 714 Code Smell Website page 4 of 4 725 EA Smell Website page 1 of 4 74
11
6 EA Smell Website page 2 of 4 757 EA Smell Website page 3 of 4 768 EA Smell Website page 4 of 4 77
12
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
RampD Research and Development
APM Agile Project Management
EAF Enterprise Architecture Framework
EAQF Enterprise Architecture Model Quality Framework
13
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
14
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
List of Tables
41 List of Code SmellsAntipatterns 43
10
List of Figures
11 A collaboration among Business Technology amp Operation 1812 Enterprise Architecture as a Cross-layer View of 1913 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (a) Functionality levels[27] 2014 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (b) dependency levels[27] 2015 The technical debt landscape On the left evolution or its challenges
on the right quality issues both internal and external[39] 2116 Relation Between Technical Debt amp EA Debt as a sub-domain of Tech-
nical Debt 22
31 Output with SDLC and Avoiding SDLC 3032 Scrum Process[19] 3433 Scrum Methodology 35
41 Different parts of SmellCull Architecture 4142 Sequence Diagram from High Level view 4643 Using Multilevel Modelling to create Customized Model 4744 An illustration of combining models into pojoModel 4845 Automation Process using UML Class Diagram 5046 Welcome page of Web Application 5147 Scenario after uploading the files 5248 Identification of EA Debts 53
51 EA Debt for different Domain of Model 5752 Dead Component at ldquoDeprecated Processrdquo 5953 Shared Persistency at ldquoPassenger databaserdquo 6054 Weekend Modularity at ldquoAirline administration supportrdquo 61
1 Code Smell Website page 1 of 4 692 Code Smell Website page 2 of 4 703 Code Smell Website page 3 of 4 714 Code Smell Website page 4 of 4 725 EA Smell Website page 1 of 4 74
11
6 EA Smell Website page 2 of 4 757 EA Smell Website page 3 of 4 768 EA Smell Website page 4 of 4 77
12
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
RampD Research and Development
APM Agile Project Management
EAF Enterprise Architecture Framework
EAQF Enterprise Architecture Model Quality Framework
13
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
14
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
List of Figures
11 A collaboration among Business Technology amp Operation 1812 Enterprise Architecture as a Cross-layer View of 1913 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (a) Functionality levels[27] 2014 Architecture scales for measuring complexity Adapted from Sessions
amp Salingaros (b) dependency levels[27] 2015 The technical debt landscape On the left evolution or its challenges
on the right quality issues both internal and external[39] 2116 Relation Between Technical Debt amp EA Debt as a sub-domain of Tech-
nical Debt 22
31 Output with SDLC and Avoiding SDLC 3032 Scrum Process[19] 3433 Scrum Methodology 35
41 Different parts of SmellCull Architecture 4142 Sequence Diagram from High Level view 4643 Using Multilevel Modelling to create Customized Model 4744 An illustration of combining models into pojoModel 4845 Automation Process using UML Class Diagram 5046 Welcome page of Web Application 5147 Scenario after uploading the files 5248 Identification of EA Debts 53
51 EA Debt for different Domain of Model 5752 Dead Component at ldquoDeprecated Processrdquo 5953 Shared Persistency at ldquoPassenger databaserdquo 6054 Weekend Modularity at ldquoAirline administration supportrdquo 61
1 Code Smell Website page 1 of 4 692 Code Smell Website page 2 of 4 703 Code Smell Website page 3 of 4 714 Code Smell Website page 4 of 4 725 EA Smell Website page 1 of 4 74
11
6 EA Smell Website page 2 of 4 757 EA Smell Website page 3 of 4 768 EA Smell Website page 4 of 4 77
12
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
RampD Research and Development
APM Agile Project Management
EAF Enterprise Architecture Framework
EAQF Enterprise Architecture Model Quality Framework
13
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
14
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
6 EA Smell Website page 2 of 4 757 EA Smell Website page 3 of 4 768 EA Smell Website page 4 of 4 77
12
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
RampD Research and Development
APM Agile Project Management
EAF Enterprise Architecture Framework
EAQF Enterprise Architecture Model Quality Framework
13
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
14
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
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
RampD Research and Development
APM Agile Project Management
EAF Enterprise Architecture Framework
EAQF Enterprise Architecture Model Quality Framework
13
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
14
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
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
14
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
Acronyms Abbreviations
AGILE Advanced Generation of Interoperability for Law Enforcement
RUP Rational Unified Process
UI User Interface
SE Software Engineering
JSP Java Server Page
15
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
Chapter 1
Introduction
Introduction can be claimed as the most important part of any report or presentationthe introduction presents a problem the reason why it has to be solved what isnecessary information to solve the problem and what is not considered part of theproblem This introduction first introduces Motivation and Goals then backgroundliterature followed by research questions finally narrates about the delimitationRounding up is the outline of the project report
11 Motivation
In the software development industry technical debt is regarded as a critical issuein terms of the negative consequences such as increased software development costlow product quality decreased maintainability and slowed progress to the long-termsuccess of developing software[82][16] Technical debt narrates the delayed technicaldevelopment 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 hasreceived rising attention as a result of a growing need to handle the degrading qualityof software and avoid costly re-engineering and maintenance
However it is vital to align Information Technology(IT) and business in order torealize the full benefits and potentials of those IT investments[54] From therethe concept of Enterprise Architecture (EA) has evolved as a method to facilitatethe alignment of IT systems and business strategies within dynamic and complexorganizations[91] Consequently the huge interest in EA resulted in vast scientificcontributions that address a broad thematic spectrum including EA frameworks EAmanagement and EA tools[25] Adapting the concept of technical debt in the EAdomain a new metaphor ldquoEnterprise Architecture debt (EAD)rdquo has been proposedrecently to provide a holistic view[29]
In the real worldTechnical debt is not necessarily a negative thing to incur same
16
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
goes to EA debt to be held in an enterprise The danger of debt comes into placewhen there is no proper debt management approach to prioritize which debt should berepaid as soon as possible Code smells can be an indicator of factors that contributeto technical debt[90] Code Smells are certain structures in the code that indicateviolation of fundamental design principles and negatively impact design quality Codesmells are usually not bugs they are not technically incorrect and do not prevent theprogram from functioning[62] Instead they indicate weaknesses in design that mayslow 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 Smellscan be identified on its design state then developers can rely on it or even afterwardresulting in a quality of data in EA repositories[71] EA Smells can be seen as acounterpart for Code Smells They serve as negative examples and bad habits thatimpair 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 correspondingsymptoms causes consequences and solutions should be mentioned[71]
There is an absence of an extensible framework to Enterprise Architecture Debtswhilst technical debt framework is readily discussed in the software industry So itbecomes crucial to develop a tool and methodologies to bridge the gap between theacademic and practitioner communities concerning the nature of the EA debt In thisthesis SmellCull as an extensible tool has been introduced for capturing tracking andmanaging Enterprise Architecture debt in the EA field SmellCull allows measuringdifferent kinds of Enterprise Architecture debts for EA Model The tool will identifythe EA Debt with extensible architecture introduce a multilevel-modeling increasethe quality of Enterprise Architecture Systems(EAS) and practices to avoid thesecommon bad habits
12 Goals
The danger of this new metaphor Enterprise Architecture Debt (EAD) comes intoplace when there is no proper debt management approach to prioritize This thesisaims to provide the framework for an extensible tool that allows measuring differentkinds of EA debts also provide techniques that it can be extended in future
13 Background
131 Enterprise Architecture
Enterprise Architecture (EA) is defined in many significantly diverging ways Amongthose Saint-Louis conducted an SLR (Systematic Literature Review) and found mul-
17
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
tiple definitions of EA[29] Therefore I regard EA as a set of artifacts which areaggregated Kappelman pointed out that ldquoThe lsquoenterprisersquo portion of EA is under-stood by some as a synonym to lsquoenterprise systemsrsquo yet by others as equivalent tolsquobusinessrsquo or lsquoorganizationrsquo[29] Even less uniform is the understanding of the mean-ing of lsquoarchitecturersquo The most common understanding of the term is a collectionof artifacts (models descriptions etc) that define the standards of how the en-terprise should function or provide an as-is model of the enterpriserdquo However EAhelps to face ldquoongoing and disruptive changerdquo by attempting to align IT and businessstrategy[29]
Enterprise Architecture is a complete expression of the enterprise a master planwhich rdquoacts as a collaboration forcerdquo between aspects of business planning such asgoals visions strategies and governance principles aspects of business operationssuch as business terms organization structures processes and data aspects of au-tomation such as information systems and databases and the enabling technologicalinfrastructure of the business such as computers operating systems and networks[72]Figure 11 is showing the collaboration among Business Technology amp OperationIn a large modern enterprise a rigorously defined framework is necessary to be able tocapture a vision of the rdquoentire organisationrdquo 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 aholistic way
Figure 11 A collaboration among Business Technology amp Operation
A fundamental principle that can be applied to EA is rdquoAlways design a thingconsidering it in its next larger context - a chair in a room a room in a house a housein an environment an environment in a city planrdquo[72]
From the above analysis it has been clear that the definitions can vary But Enterprise
18
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
Architecture usually includes several different layers of the enterpriseA schematicillustration can be seen in Figure 12 with the proposed Layers of Business Archi-tecture Process Architecture Integration Architecture Software Architecture andTechnology Architecture Winter and Fischer introduced a scheme based on thefoundation that ldquoMost of the artifacts [ ] in EA can be represented as aggre-gation hierarchiesrdquo The different domains of EA interact with each other while thecomponents of each corresponding domain are organized in their own hierarchies[87]
Figure 12 Enterprise Architecture as a Cross-layer View ofAggregate Artifacts by Winter and Fischer[87]
132 Multilevel Modelling
One of the most serious limitations of the Enterprise Architecture Model in practiceis its inability to cope with complexity With large numbers of entities data modelsbecome difficult to understand and maintain The problem becomes unmanageable atthe enterprise level where models typically consist of hundreds of entities A numberof approaches have been proposed in the literature to address this problem but nonehave achieved widespread acceptance in practice[49] The Model may be organizedinto any number of levels depending on its complexity[49] The technique is calledmultilevel modeling which is based on the organization of a city street directory whichis a practical solution to the problem of representing a large and complex model ineveryday 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
19
Multi-level modeling (also called deep metamodelling) extends the standard approachto metamodelling by enabling modeling at an arbitrary number of meta-levels[43]Multi-level models are particularly appropriate for research designs where data forparticipants are organized at more than one level While the lowest level of data inmulti-level models is usually an individual The highest level of data is comparedwith the previous model to assess better model fit
Figure 13 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (a) Functionality levels[27]
Figure 14 Architecture scales for measuring complexity Adapted from Sessions ampSalingaros (b) dependency levels[27]
20
Multi-level models can be applied on data with many levels Figure 13 andFigure 14] shows functionality and dependency in multi-level model In this projectwe also use Multilevel Modelling by making a customised model to implement theextensible framework This thesis uses a Model with multiple level because it leadsto simpler model descriptions[43] Here it will also make data distribution and modelmodification easy
133 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 developmentcost low product quality decreased maintainability and delayed progress to the long-term attainment of developing software[81] [16] Technical Debt narrates the delayedtechnical 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 inwhich software developers allow compromises in one dimension to meet an immediatedemand in another dimension and resulted in higher costs to restore the health of thesystem in future[74]
Moreover Technical Debt is explained as the effect of immature software artifactswhich requires extra effort on software maintenance in the future[28] While theTechnical Debt metaphor has further extended to include design debt which de-scribes the immature design decisions[4] the context of Technical Debt is still limitedto the technological aspects
Figure 15 The technical debt landscape On the left evolution or its challenges onthe right quality issues both internal and external[39]
Figure 15 shows a possible formation of a technical debt landscape Visibleelements 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 leftit is dealing primarily with evolution or its challenges whereas on the right it is
21
dealing with quality issues both internal and external Technical Debt often refersto invisible elements
134 Enterprise Architecture Debt
However the concept of Technical Debt that specifically focuses on technical aspectsdemonstrates a deficiency of attention to attaining a holistic perspective to locate thealignment between business and IT aspects Whilst enterprise architecture (EA) isgaining significant attention as a management instrument in business and IT[42]
Enterprise Architecture Debt is a metric that depicts the deviation of the currentlypresent state of an enterprise from a hypothetical ideal state EA Debt arises whendebt is taken in an artifact which an EA consists of This means that an elementis not implemented or executed optimally in relation to the supposed ideal situationTaking debt in a low hierarchy can be helpful and pay off but it has to be ldquorepaidrdquoin accordance to business related goals Otherwise the whole EA would rely on thatdebt and use faulty or considered bad artifacts This entails a high risk of additionaldebt and hinders the development EA Debt is further increased by bad interfaces orbad interoperability and different priorities of stakeholders not conform with an EAthat is considered good by evaluation approaches[29]
Figure 16 Relation Between Technical Debt amp EA Debt as a sub-domain of TechnicalDebt
Further we can relate Technical Debt to EA Debt as a sub-domain of it (cfFigure 16) that is related to the software and technology aspects However thereare also issues related to EA Debts on software and technology aspects that are stillnot covered by Technical Debt Those issues can be interalia their relations amongeach other or the adherence to overarching business goals[29]
22
135 Code Smell
Code smells are symptoms of poor design and implementation choice It has been thesubject of several empirical studies mainly intended at characterizing them and atmeasuring their impact on the maintainability of software systems It is well-informedthat 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 givenby Fowler and Beck such as ldquocertain structures in the code that suggest (sometimesthey scream for) the possibility of refactoringrdquo [24] are common bad habits that canimpair the quality of a software system or the software architecture when they areignored Like anti-patterns they are seemingly good solutions that are commonlyand 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 ldquothe ease with which a softwaresystem or component can be modified to correct faults improve performance or otherattributes or to adapt to a changed environmentrdquo[1] Mantyla and Lassenius adaptedthis term to software evolvability which refers to ldquothe ease of further developing asoftware elementrdquo [48] This has a close match with the term perfective software main-tenance of IEEE which is defined as ldquosoftware maintenance performed to improve theperformance maintainability or other attributes of a computer programrdquo[1]
Some reasons for happening Code smells has been observed
bull Defect of Software design in the time of creation
bull As a result of maintenance and evolution activities
bull When new features and enhancing functions are added
bull For the pressure of production developers tends to do mistakes in development
bull Excessive use of design patterns can also be a cause
14 Research Questions
To develop an extensible tool that will detect EA Smells automatically there aresome steps which have to be taken into account These research questions will guidethe process of finding suitable answers to the open problems and structure the courseof action
bull Question1 How the architecture of this tool should be sketched that is robustto future extensions
bull Question2 What type of input format should be chosen for the tool
23
bull Question3 How the tool could be more generalized for different types of EAModel
bull Question4 What the EA debt detection tool will do in the field of EnterpriseArchitecture
bull Question5 Does any Web service APIs such as REST-API could be integrate-able to the tool environment
15 Delimitations
This degree project focuses on the Enterprise Architecture Debt only for model andnot the entire Enterprise Architecture The attention will paid mostly to the Enter-prise Architecture Components relationships interconnections and hierarchy betweenthem The excluded parts are methods process flow etc The project is not respon-sible for supporting statistics processes and management of the EA systems theproject is bounded only for supporting the Enterprise Architecture Model at basicadvanced and research levels
On account of our resource and time limitation the investigations were confinedonly to the following EA debt
bull Ambiguous Viewpoint
bull Chatty Service
bull Cyclic Dependency
bull Data Service
bull Dead Component
bull Dense Structure
bull Documentation
bull Duplication
bull Hub-like Modularization
bull Lazy Component
bull Message Chain
bull Shared Persistency
bull Strict Layers Violation
24
bull Weakened Modularity
25
Chapter 2
Related Work
Since not much work specifically deals with EA Smells as an indication for a modelrsquosquality directly So different topics have to be investigated The chapter is divided intotwo different categories First studies that occupy the framework analysis regardingEA models The next section mentions various types of Enterprise Architecture Toolavailable on the market and how this thesis can extend prior work
21 Enterprise Architecture Model Quality Frame-
work amp 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 AnEnterprise Architecture Model Quality Framework (EAQF) was developed by Timmet al that structures relevant information and helps enterprise architects to reflecton their EA models[80] This framework constracts upon six principles to assess anenterprise modelrsquos quality by Becker Probandt and Vering namely the principlesof validity relevance economic efficiency clarity systematic model structure andcomparability[33] Besides Pitschke provides a list of quality attributes and explainsthem in relation to business process models[64]
A very popular framework for ascertaining the success of information systems is TheDeLone and McLean Model of Information Systems Success most lately updated in2003[18] This was adapted specifically to the domain of EA by Lange Mendling andRecker depicting EA product quality EA function setup quality EA service deliveryand EA cultural aspects as components influencing the satisfaction and the intentionof use[41]
A tool developed by Robert Lagerstrom using a probabilistic mathematical frame-work is demonstrated for analysis of enterprise architecture models[20]The tool guidesthe creation of information system scenarios in the form of enterprise architecturemodels and calculates assessments of the scenarios as they evolve This tool focuses
26
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 Lagerstrom and Pontus Johnson[84] They contribute a metamodel thatsupports the creation of enterprise architecture models amenable to service interop-erability analysisThe metamodel consists of entities with accompanying attributesthat can be used to create enterprise architecture models from which it is possibleto extract precisely the information that is needed for quantitative enterprise serviceinteroperability analysisAnother enterprise architecture metamodel for maintainabil-ity modeling and analysis is presented Robert Lagerstrom[70]
Recently Johannes Salenti has introduced EA debt concept and shown some EAdebt detection technique on EA model But it is mostly a catalog related to EAsmells not any framework for any tool of EA debt detection[71]
22 Different types of Debt Management tool
Since a tool to identify EA debt will be developed some debt dedicated tools whichmanaging and identifying TD should be analysed This will give us an overall idearegarding Debt detection tool and also how can proceed to make a tool A numberof debt detection and management tools are available on the market Few numbersof them are following bellow
Software maps tool is one of the debt management tool for Monitoring code qualityand development activity by software maps[12] This provides automated softwareanalysis and monitoring of both quality-related code metrics and development activ-ities by means of software maps A software map represents an adaptive hierarchicalrepresentation of software implementation artifacts such as source code files beingorganized in a modular hierarchy The maps can express and combine informationabout software development software quality and system dynamics they can sys-tematically be specified automatically generated and organized by templates Themaps 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 Theapproach 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 technicaldebt in software projects DebtFlag integrates into the development environment and
27
provides developers with lightweight documentation tools to capture technical debtand link them to corresponding parts in the implementation But in the perspective ofEnterprise Architecture domain existing concept of DebtFlag is not appropriate[31]
Another Debt management tool is Sonar TD plugin for dentifying and measuringTD 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 toolto identify Enterprise Architecture Debt(EA Debt) In this thesis I have developed aframework to measure Enterprise Architecture Debts
28
Chapter 3
Effectively utilizing Life Cycle
This segment explains the Software Development Life Cycle used in this degreeproject Explained first is the general Software Process Model method with theirpros and cons Also why Scrum has been chosen to which this degree project adheresto The second section(52) described principle of Scrum and third section(53) areregarding the Scrum phase Lastly follows the Scrum throughout the whole projectin order to achieve the results
31 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 theirRampD capacity and capability with many technologies complex roadmaps of multiplevariants and unclear value contributions of products and new features[19] Projectlife-cycle management is still insufficiently practiced
On the other hand projects run without concrete and quantitative objectives andwithout tracking where they are with respect to expectations Project proposals areevaluated in isolation from other ongoing activities Projects are started or stoppedbased on local criteria not considering the global trade-offs across all projects andopportunities Only one-third of all software engineering companies have techniquesto effectively share knowledge on their products and development projects [19]
Figure 31 shows the outcome with Software Development Life Cycle(SDLC) andwithout 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 deliveryThe 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 toexist long after the project that delivered it has closed Therefore the SDLC providesguidelines for supporting the product post-production Procedures include practices
29
for knowledge transfer Code turnover It is a entire circle in a systemrsquos life So tofollow SDLC will be beneficial for the future development of our tool[47]
Figure 31 Output with SDLC and Avoiding SDLC
To some general life cycle called Software Process Models are used These areWaterfall 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
30
etc[66][67][15][17][69]
Neither of the waterfall model nor the Spiral model deals well with frequent changeThe Waterfall model assumes that once you are done with a phase all issues coveredin that phase are closed and cannot be reopened The Spiral model can deal withchanges 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 andadjusting scope are difficult and expensive Software is developed during the imple-mentation phase so no early prototypes of the software are produced The model doesnot 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 Activitiesperformed in parallel are subject to miscommunication and mistaken assumptionsUnforeseen inter-dependencies can create problems Changes are possible as it is aniterative model[66]
Incremental model starts with an initial planning and ends with deployment withthe 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 alsorequires a good planning designing RAD Model is flexible and adaptable to changesbut its is more complex to manage comparing to other models[67]
The lean SDLC methodology mostly focuses on reducing waste If developers andoperations people do not establish clear lines of communication and transparencyfrom the start the security of the software might suffer leading to crippling setbacksand 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 ifthe requirements are misunderstood in the beginning you could get to the end andrealize the project may have to be started all over again[69]
In comparison to others Agile model is gaining popularity in the industry althoughthey compromise a mix of accepted and controversial software engineering practicesItrsquos typically more suitable for smaller projects and itrsquos not preferred for long-termprojects where you have to know every tiny detail[7] The software industry wouldmost probably find that specific project characteristic such as the objective scoperequirements resources architecture and size will determine which methodology suitsthem best In the previous years anecdotal evidence and success stories from prac-ticing professionals suggest that agile methods are effective and feasible for manysituations and environments Agile model supports individuals and interactions overprocesses 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
31
It includes Customer collaboration over contract negotiation and allows changes overfollowing a plan[34]
When an appropriate model is applied according to the requirements the successrate of software projects can increase There is no perfect model existing Everythingdepends upon the project and its characteristics like nature of the project developerrsquosskills and management support[6]
In our project itrsquos essential to move quickly and easily and to respond swiftly tochange Our project involves Continuous Integration (CI) which indicates keepingthe code up to date by producing a clean build of the system a few times per dayThis project support with a rule stating that the programmer never leaves anythingunintegrated at the end of the day it gives the authority to deliver a product versionsuitable for release at any moment What to do is to minimize the time and effortrequired by each integration
Itrsquos a small project consist of 2 members while one involves lsquodrivingrsquo (coding imple-mentation etc) and the other lsquonavigatesrsquo (such as observing providing feedback)Every process of the project is added to meet the requirements The time durationis not long-termed and approximately six months This project needs iterations likemultiple releases and delivers the complete product at the end of the final iterationImplement test repeat and then release are needed to provide the framework Soit can be called iterations From the perspective of testing we need to find defectsand fix them immediately This project is developing a framework So a flexibleapproach is the searching to product development For these reasons agile model ischosen as the project development life cycle
In the area of project management the term ldquoagile managementrdquo became knownfrom 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 werenamed ldquoagilerdquo and their creators got together and prepared a manifesto which wascalled the Manifesto for Agile Software Development[83]
Since then several studies have been conducted on the topic of ldquoagilityrdquo and theseprocesses have become known under the general acronym for agile project manage-ment (APM) [14] Scram methodology has been used in our project because of itis an adaptive iterative fast flexible and effective methodology designed to deliversignificant value quickly and throughout a project development[21]
32
32 The principle of Scrum
The key points of Scrum are discussed below[35] and the Scrum process is shown inFigure 32
bull Product Backlog - This is the prioritized list of all features and changes thathave 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 formaintaining the Product Backlog
bull Sprints - Sprints are usually between 14 and 30 days in length it is the proce-dure of adapting to the changing environmental variables (requirements timeresources knowledge technology etc) and must result in a potentially ship-pable increment of software The working tools of the team are Sprint PlanningMeetings Sprint Backlog and Daily Scrum meetings[51]
bull Sprint Planning meeting ndash Sprint planning meeting is first attended by thecustomers users management Product Owner and Scrum Team where a set ofgoals and functionality are decided on Next the Scrum Master and the ScrumTeam focus on how the product is implemented during the Sprint[51]
bull Sprint Backlog ndash It is the list of features that is currently assigned to a particularSprint When all the features are completed a new iteration of the system isdelivered[51]
bull Daily Scrum ndash It is a daily meeting for approximately 15 to 30 minutes whichprovides enough time to address obstacles but does not allow time to brainstorma solution[30]
33
Figure 32 Scrum Process[19]
The Scrum process may alter the job description and customs of the Scrum projectteam notably For example the project manager ie the Scrum Master does nolonger needs to organize the team but the team organizes itself and makes decisionson what to do Ken Schwaber illustrates ldquoMost management is used to directing theproject telling the team what to do and then ensuring they do it Scrum relies onself-organization with the team deciding what to do while management runs inter-ference and removes roadblocksrdquo [34]
Scrum has been successfully used over thousands of projects in 50 organizations pro-ducing significant productivity improvement Rising and Janof suggest that ldquoClearlyScrum is not an approach for large complex team structures but found that evensmall isolated teams on a large project could make use of some elements of ScrumThis is true process diversityrdquo
34
33 Scrum Phase
Figure 33 Scrum Methodology
Figure 33 shows the main phases and steps of the SCRUM methodologyEach of the phases has the following steps
PlanningThe first step is making the backlog - a list of essential properties that have to beimplemented during the development process The product owner is a person respon-sible for this He bases on information from customers situation on the market andcompetition requirements and knows which functions or properties of the product arethe 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 Releasecost(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 anexisting system that need to be enhanced(by adding some new functions)it will bringthe phase to quite brief analysis[73]
35
ArchitectureHigh Level DesignAfter 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 theimplementation process Sometimes as it was said before there is a need to makesome changes refine the old product learn some additional knowledge analysis solveproblems or issues which appear during the process In the end there are designedreview meetings during which the teams exchange information present progress andproblems reassigned changes as required[73]
Development (Sprint)The Development phase is an iterative cycle of development work Managementfixes that time competition quality or functionality are met iterations are and theclosure phase occurs This approach is also called as Concurrent Engineering[73]Development consists of the following macro processes
bull Meeting with teams to review release plans
bull Distribution review and adjustment of the standards with which the productwill conform
bull Iterative Sprints until the product is deemed ready for distribution
A Sprint is a set of development activities directed over a predefined period usuallyone to four weeks The interval is decided on product complexity risk assessmentand degree of oversight wished for Sprint speed and intensity are led by the selectedduration of the Sprint Risk is assessed continuously and adequate risk controls andresponses 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 requirementsinto packets opening the packets performing domain analysis designing developingimplementing testing and documenting the changes Development consists of themicro process of discovery invention and implementation[73]
Wrap Closing the packets creating a executable version of changes and how theyimplement 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 appropriateresponses defined[73]
Adjust Consolidating the information gathered from the review meeting into af-fected packets including different look and feel and new properties[73]
36
ClosureWhen the management team realizes that the variables of time compe-tition requirements cost and quality concur for a new release they declare therelease rdquoclosedrdquo and enter this phase This phase prepares the developed productfor general release Integration system test user documentation training materialpreparation and marketing material preparation are among closure tasks[73]
34 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 amp student) of this project
bull In the beginning the prioritized list of all features and changes such as makethe framework extensible has chosen data will be structured and accessed usinga customised model(see rdquopojoModelrdquo package in Figure 45) remove the de-pendency from auto-created model(see rdquomodelrdquo package in Figure 45) shouldbe added a monitoring panel Also define the delivery date and functional-ity of one or more releases These plannings are described within our projectproposals which has been submitted in March
bull To architect high level design domain analysis has performed to the extentrequired like literature review and research analysis of previous work to buildenhance or update the domain models to reflect the new system context andrequirements Refine the architecture again to support the new context andrequirements And the problems or issues in developing and implementing thechanges are identified
bull Our Sprints are 14-days in length and each Sprint contains a Planning MeetingsIn every sprint the procedure of adapting to the changes has been discussed andmust result in an upgrade of the project Sprint planning meeting is attendedby supervisor amp student where a set of goals and functionality are decided onThe Scrum Master was the supervisor throughout the whole sprints
bull As our thesis is a remote work environment due to the COVID-19 pandemicso the sprint work has been spilled into some small parts as the result of DailyScrum meetings Obstacles are faced by the team and to keep track of theprogress mail communication has been used For the version control mecha-nism github has been used
bull Each Sprint consists of develop wrap review and adjust phase
bull Discovery invention developing implementing testing and documenting thechanges has been followed for develop phase I have developed new changes orthe backlog in develop phase I am responsible for maintaining the Backlog
37
bull In the warp phase of our project Creating an executable version of changes wasthe main target
bull Work and review progress raising and resolving issues and problems addingnew backlog items has been presented in sprint meetings for review Risk isreviewed and appropriate responses are defined also
bull Adjust phase has been done by consolidating the information gathered from thereview including different look and feel and new properties
bull 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 orcomplete then a phase can enter to the closure phase As an example I de-fined rdquoclosedrdquo for the pojoModel implementation when the must have featuresintegration testing has been completed
38
Chapter 4
Implementations
After defining the EA Smells it is now time to draft the tool that is capable ofdetecting smells First some challenges and general requirements are mentionedin section 41 before explaining the basic structure of the SmellCull in section 42The list of EA Smells currently detected by the tool has demonstrated in section43 The implementation of the tool is Dissected in section 44 then showing theinteraction between user and tools in section 45 Finally limitations to the programand automatic detection in general are presented(section 46)
41 Challenges amp 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 theinput The tool should be intuitive enough to for non-technical users detect the 14EA smells accurately and efficient in processing the inputs
The EA model can be compliant with windows XML format XML should be createdusing appropriate protocols and the XML has a certain formatThe XML file shouldbe provided by the user by maintaining this certain format The validator will checkthe XML either it is valid or not In case of invalid The system will show a errorand it will not execute further process of EA Debt detectionThis is a critical issuebecause the sources of information that can be exploited will be based on this XMLfile
Transformation rules and mapping should be followed for model-to-model transfor-mation Data exchange between auto created model to customised model shouldbe done very carefully through another Layer However the multilevel modelling ofthis mechanism can lead to rather complex strategy for very simple tasks From theanalysis of the state of the art a set of rule as well algorithm has implemented forevaluating EA Model
39
Since one has to be able to easily modify existing and add new detection strategy tothe current algorithm for new smells the opportunity to run tests or the programitself 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 featureson the customised model In particular for customised Model one can analyze thestructural dependencies between the entities of classes ie attributes and methodsin order to build for each entity the entity set ie the set of methods using it
Still the detection of many smells can be challenging because the functionality isnot implemented directly within any source such that no similar indications meth-ods are available Hence too little information can be apparent to detect specificsmells automatically which asks for manual assessmentMore investigation analysisand technique regarding EA smells identification is needed to handle these challenges
42 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] bySimon Hacks This structure is extended in the SmellCull mechanism in order todecompose entries into reusable components as well as to properly present EnterpriseArchitecture debt at the implementation level
The SmellCull is a four parted approach on managing EA debt with a more holisticview of the enterprise Every part will be discussed here in succession SmellCullmaps all of the parts as a framework and how they relate and interact to fulfill thesismission Figure 41 shows the major parts(The blue filled rectangle) sub-parts(Thewhite 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 aboutthis part will be discussed later in section 45 It will act like more likely User In-terface(UI) and rest of the parts will be used for Identification Processing Welcomepage(Figure 46) of webapp will handle input files and Thanks page(Figure 48) ofwebapp will visualize the results of Identification Processing
Another part is the SmellCull customised modelSmellCull takes a set of informa-tion for EA Model A description explains the modelrsquos structure including relationelements property strategy organisation view etc for its acquirance An estimatefor the modelrsquos principal indicates how much resources are required to pay it back -to make this partition fully adhere to the designHere the model can be popularisedeither using auto-created model or the documents dataExchange Layer has been
40
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 smellswhich 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 DIrsquos location is not limited to a single areapredefined by the implementation technique but rather it can encompass an unlim-ited amount within Enterprise Architecture and combination of them This makes itpossible for a single DI to have unrestricted propagation capabilities At the sametime the possibility to use any critical issue as equals to DI is kept
Figure 41 Different parts of SmellCull Architecture
Finally the fourth part are smells used to identify different EA Debt Item Thispart will marking out the location and give a description regarding where and how theEA Debt is found The rule of Identifying each Debt Item is different and separate Itincludes a name like Ambiguous Viewpoint and a identification rule for it The nameis self-explanatory The rules will be applied to the Customised model according tothe DL
41
43 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 approachedand the tool for their automatic identification Table 41 reports the list of suchcode smells as well as anti-patterns detected by the SmellCull while the descriptionof 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 thetable we represent also allows to understand the difference between code smells andanti-patterns Specifically code smell represents something ldquoprobably wrongrdquo in thecode while an anti-pattern is certainly a design problem in source code In otherwords a code smell might indicate an anti-pattern[10]
42
Table 41 List of Code SmellsAntipatterns
AntipatternName
Description Aliases Sources
AmbiguousViewpoint
Object-oriented analysis and de-sign (OOA amp D) models are of-ten presented without clarifyingthe viewpoint represented by themodelThis is called AmbiguousViewpoint
[2]
Chatty Service Chatty Service is an antipatternwhere a high number of operationsare required to complete one ab-straction where the operations aretypically attribute-level setters orgetters
CRUDy Inter-face Maybe It isNot RPC
[59][56][57][52] [60]
Cyclic Depen-dency
A cyclic chain of calls between mi-croservices exists
Cyclic Hierar-chy Cyclically-dependentModularization
[78][68][32] [53]
Data Service Data Service typically contains ac-cessor operations ie getters andsetters In a distributed environ-ment some services that may onlyperform some simple informationretrieval or data access operationsA Data Service usually deals withvery small messages of primitivetypes and may have high data co-hesion
Data Class [85][48][61][76][9][24][59][56] [57]
Dead Compo-nent
A variable parameter fieldmethod or class is no longer used(usually because itrsquos 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
43
AntipatternName
Description Aliases Sources
Duplication Corresponds to a set of highly sim-ilar services
DuplicatedCode Toomany CooksUnfactored Hier-archy SoftwareCloning 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 largenumber of other abstractions
Bottleneck Ser-vice
[9] [53][60]
Lazy Component A class methods or attribute thatdoes not do anything
Lazy ClassPoltergeistFreeloaderUnnecessary Ab-straction GypsyProliferation ofClasses ig DoItController Class
[9] [24][85][48][75][46][76] [9]
Message Chain Watch out for long sequences ofmethod calls or temporary vari-ables to get routine data Inter-mediaries are dependencies in dis-guise
Percolating Pro-cess ServiceChain
[24][32][53][85][48][76] [9]
Shared Persis-tency
Different microservices access thesame relational database In theworst case different services ac-cess the same entities of the samerelational database
Data Ownership [79]
Strict Layers Vi-olation
This violation very often occurs inthe real world although the modelitself defined the layers and pro-cesses precisely Of course theremay be implicit relations that canbe derived which actually connecttwo separate layers
[46]
Weakened Mod-ularity
Each module must strive for highcohesion and low coupling Thissmell arises when a module ex-hibits high coupling and low co-hesion
The Knot Ar-tificial CouplingCode at WrongLevel of Abstrac-tion
[60][32][53] [75]
44
44 Automation of SmellCull
Figure 42 represents the basic functionalities of the tool through a Sequence Di-agram It is an interaction diagram that describes how operations are carried outhere They capture the interaction between objects in the context of a collaborationSequence Diagrams are time focus and they show the order of the interaction visuallyby using the vertical axis of the diagram to represent time what messages are sentand when[11]
This project is implemented through System sandwich approach which is an ingeniousapproach for building and maintaining software or tool The idea is to sandwich thesystem between a front-end interface (eg 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 Automationprocess depends on Backend and Pre-Processing as well as Post-Processing dependson Front-end Backend will be described in this section which is the AutomationProcess and will recite Frontend in the next subsection(section 45)
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 DevelopmentKit (JDK) 11 is used because it supports the xjc tool for auto generating classesfrom the ArchiMate schema (archimate3_Diagramxsd)The auto generated classesof the model are located in a separate package (see ldquomodelrdquo package in Figure 45)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 Thisprocess is called unmarshalling and provides the content of the XML-file as objects(class JAXBMarshalUnmarshal)
45
Figure 42 Sequence Diagram from High Level view
46
For making the tool extensible transferring the data to a customized model asnew type of model can be adjustable for the requirements For instance the autogenerated model is created using xjc tool and XML binding is used to load an XMLinstance of a model one can add new approaches for binding or new model whichcan be transformed to the customised model But this can not be done by using onlyauto generated Model This is because every classes of auto generated Model(seeldquomodelrdquo package in Figure 45 is auto created and not modifiable according to therequirements of the tool The classes of the customised model are located in anotherpackage (see ldquopojoModelrdquo package in Figure 45)
To create the customized model(see rdquopojoModelrdquo package in Figure 45) we haveapplied model-to-model transformation and then used multilevel modeling(see Fig-ure 43) In Figure 43 it is clear that motivation and strategy belongs to higherlevel because they are organizationsrsquo specific goals oriented and rest of the othersincluding element property structure relations view are within lower level As onlyone auto generated model right now exists so transformation has done between autogenerated model-to- customised model But the foundations for achieving model-to-model transformation have not yet been built[86] Normally model transformationrules 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-modelmappings and transformations lies in detecting the semantics and semantic relationsthat are conveyed in different models Both of the semantic and syntactic checkingmeasurements are combined into auto created model-to-customised model mappingsand transformations[86] In addition other auto-created model can also be integratedto the customised model(see rdquopojoModelrdquo package in Figure 45)
Figure 43 Using Multilevel Modelling to create Customized Model
47
Figure 44 An illustration of combining models into pojoModel
To exchange the data from model to model another layer called dataExchange isused hereIt will facilitate the use of customised model classes and provide additionalfunctionality that is employed by the Detectors a ModelAdapter(see rdquoadapterrdquo pack-age in Figure 45) is created as a layer of indirection It uses the JAXB class forunmarshalling the provided model to Java objects As a consequence the complexstructure of the customised model(see rdquopojoModelrdquo package in Figure 45) gets hid-den by more intuitive methods The class EASmellDetector(see rdquoadapterrdquo packagein Figure 45) manages all Detectors and calls their detect methods and transfer theresults to the HelloController (see rdquomainrdquo package in Figure 45) HelloControllerprovides information to the user by printing all collected EA Smells through the WebApplication(Figure 48) In the next subsection(section 45) web application partwill be described in details When executing the program one has to specify at leastthe EA Model instance (as XML-File) that is to be checked and optionally as secondargument the schema to verify against (as XSD-File)
For each smell there is a separate detector class located in the smells package (see
48
ldquosmellsrdquo package in Figure 45) that extends the abstract class Detector This waythe individual classes can be modified or extended conveniently A Detector has areference to the model under investigation as well as the list of detected smells andthe actual smell name In addition different constants for metrics can be accessedfrom the Constants class that encompasses different thresholds in one place Wheneventually a smell was detected by the detect() method a new EASmell with itsname the affected element and an optional context like metric values can be addedto the smells list
Overall the detection of smells is based on metrics and general architecture analy-sisThe specific detection methods for each EA smells are implemented in smells pack-age using separate classes like AmbiguousViewpoint WeekenedModularity etc(seeldquosmellsrdquo package in Figure 45)
49
Figure 45 Automation Process using UML Class Diagram
50
45 SmellCull Web Application
The SmellCull web application has been created using the Spring Boot web applica-tion framework The Spring Boot 216 is used because the Spring Boot provides agood platform for Java and our project is also build in Java
Figure 46 Figure 47 and Figure 48 depicts the SmellCull web application Fromthe first page Entering a Enterprise Architecture model and validator both as inputset we can start the application
Figure 46 Welcome page of Web Application
After uploading the necessary file the web application look like Figure 47 Thesubmit button contains the main controls From here it is possible to begin theprocedure 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 anddescribed in Section 43
51
Figure 47 Scenario after uploading the files
The 2nd page of the SmellCull web application (see Figure 48) contains detailedresults for detector list Here the representation contains the critical issues calledEA debt described in Section 43 The critical issue in terms of the negative conse-quences such as increased software development cost low product quality decreasedmaintainability and slowed progress to the long-term success of developing softwareNow the critical issues can be handled by the technical development activities of aspecific Enterprise Architecture From here it is easy to see the reasoning for whyan EA Debt for a particular Model element has happened
52
Figure 48 Identification of EA Debts
46 Limitations
The barrier for identifying EA debt is lowered as it is taking less resources(only EAmodel) not the entire Enterprise Architecture This is an unwanted side effect
The program only works for EA models compliant to The Open Group ArchiMateModel Exchange File Format Standard of the archimate3_Diagramxsd Anywaythe detection methods can be applied to other models as well but this particularimplementation relies on the described structure
The SmellCull mechanism relies onto the EA models which will be provided by userThis indicates that the burden of EA Debt Identification is placed onto the end usersThis indicates a dependency The state of EA Debt diminishes directly as a conse-quence of the end usersrsquo inability to input EA model information into the SmellCullmechanism as well as the SmellCull mechanismrsquos inability to enforce EA Debt gover-nance
Automatic detection is not complete and does not have to be correct Just becauseno smells were reported this does not imply a perfectly designed model It may bethe case that too few smells are automatically detectable or the used metrics or their
53
model are not suitable for the current environmentAlso a few number of EA Smellscurrently detected by the SmellCull It is a great phase of limitation
In order to overcome the aforementioned boundary case studies are needed toidentify problems in user experience and training as well as to develop the SmellCullmechanismrsquos ability to be cross-compatible with other EA Debt identification andassessment tools
Though there are some limitations in the SmellCull this thesis provides a supportto both researchers who are interested in comprehending the results achieved so farin the identification of EA Debt and practitioner who are interested in adopting atool to identify EA Debt in their Enterprise Architecture Systems
54
Chapter 5
Evaluation
The evaluation of an anti-pattern detection tool can consist of different steps andcan be done following different strategies such as Evaluation based on an AutomaticOracle and Evaluation based on Developerrsquos Judgment[63] In most of cases a firstevaluation has been done analyzing the accuracy in terms of metrics able to evaluatethe goodness of an approach (ie precision and recall [65])In other cases the accuracy of the tool can be evaluated directly involving developerswho express their opinion regarding the suggestions provided by the tool[63] In thissection evaluation strategies has been described first(section 51 and section 52)then evaluating the accuracy of SmellCull tool(section 53) and finally showing somedemonstration of EA Smells(Section 54)
51 Evaluation based on an Automatic Oracle
To evaluate the accuracy of a detection tool an oracle is required that reports theanti-pattern instances contained in a system Unfortunately very few software sys-tems with annotated antipatterns are available This means that to have a largerdata set for experimenting anti-pattern detection tools a manual identification of anti-pattern instances in the object systems is required to build the oracle
In particular starting from the definition of the anti-patterns reported in litera-ture the analysis of each class of a software system should be performed in orderto identify instances of those anti-patterns Once the oracle is defined the detectiontool is executed to extract the set of candidate anti-patterns Finally the two sets ofanti-patterns (ie the manually identified and the candidate sets) can be comparedand two widely-adopted Information Retrieval (IR)[65] metrics namely recall andprecision[65] can be used to estimate the accuracy of the tool
recall =|Correct capDetected|
|Correct|
55
precision =|Correct capDetected|
|Detected|
where Correct and Detected represent the set of true positive anti-patterns (thosemanually identified) and the set of anti-patterns detected by the approach respec-tively As an aggregate indicator of precision and recall F-measure ie the harmonicmean of precision and recall can be used
F minusmeasure = 2precisionrecall
precision + recall
52 Evaluation based on Developerrsquos Judgment
When an oracle reporting the list of anti-pattern instances present in the system isnot available it is possible to involve developers in order to evaluate the performanceof a detection tool It is worth noting that this is not an optimal solution becausethe developers can judge the goodness of a suggestion provided by the tool whilethey cannot evaluate the performance of the tool with respect the totality of the anti-pattern instances present in the system (ie they can judge the precision of the toolbut they can not aid in the evaluation of the recall) However this kind of evaluationis still useful in two cases
bull As complement of the analysis based on the metrics in order to understand towhat extent the tool supports the developer
bull When you have to compare the support provided by two (or more) tools Inthis case a partial oracle can be built as the union of the suggestions providedby the tools Thus both the precision and recall can be evaluated
Two kinds of studies that could be performed (i) with the original developers ofa system and (ii) with external developers The evaluations performed with originaldevelopers are preferred since external developers do not have a deep knowledge ofthe design of the subject system under analysis and thus may not be aware of someof the design choices that could appear as suboptimal but that are the results of arational choice
However studies with external developers can complement studies performed withoriginal developers In fact even if the original developers have deep knowledge of
56
the systemrsquos design they could be the authors of some bad design choices and con-sequently could not recognize good suggestions by the tool This means that the twostudies complement each other mitigating the specific threats they have
53 Evaluating the Accuracy of SmellCull Tool
Figure 51 EA Debt for different Domain of Model
For the evaluation of tool I have used automatic oracle because Evaluation basedon Developerrsquos Judgment needs external developersrsquo involvement This approach isnot feasible here as it is individual master thesis Also Developerrsquos Judgment is notan optimal solution And this thesis would not be included the cases above whereDeveloperrsquos Judgment is useful I used two model (CentralModelxml and SmellEx-amplexml) for experimenting EA debt detection tool
The CentralModelxml is a representation of an airport with 171 elements and 250relationships and is designed with a decent quality Therefore only six EA Smellsincluding one Ambiguous viewpoint one lazy component one shared persistency andthree weakened modularity were detected in this XML file
The SmellExamplexml is another example that contains detectable EA Smells It
57
contains 47 elements with 88 relationships Therefore twenty EA Smells includingone Ambiguous viewpoint one chatty service three cyclic dependency one data ser-vice two dead component two dense structure one documentation one duplicationone hub-like modularation one lazy component one message chain one shared persis-tency three strict layers and one weakened modularity were detected in this XML file
The manual identification of anti-pattern instances in the models are the same asthe automated detection by SmellCull which indicates that the tool is 100 correct
The automated detection have accomplished the steps of the manual identificationonly faster and with more accuracy Whatrsquos more automated detection can be de-signed to change data of the model along the way and allow authorized process usersto view the status of the workflow at any time Automated detection that save timesave money and ultimately achieve better more accurate results
Imagine that a model will be analysed manually then experienced analysts are (al-ways) needed which is more costly than automated detection In addition if modelwould be changed then the manual detection has to be done again It will be morecostly Also larger amount of data can be processed and no matter how big the modelis it is not a problem But in manual identification it is not only a problem butalso almost impossible to calculate EA Debt for the big model
54 Demonstration on different EA Smells
In the following Dead component shared persistency and weekend modularity willbe inspected to explain and demonstrate the behavior of the developed program Thisshould help to understand the work procedure of the tool and on the other hand thenecessity of automated detection To describe Dead component model SmellExam-plexml will be used and for shared persistency as well as weekend modularity modelCentralModelxml will be used here
Dead component A complex Dead Component can be seen in Figure 52 on page 54Although there are relations between the elements But the overall cluster rdquoDeprecatedProcessrdquo is never used and is correctly identified as a Dead Component
58
Figure 52 Dead Component at ldquoDeprecated Processrdquo
Shared Persistency In Figure 53 on page 55 the ldquoPassenger databaserdquo isaccessed by two different devices namely a ldquoFingerprint recognition devicerdquo and aldquoFace recognition devicerdquo This could imply a Shared Persistency which has to beevaluated manually Again the two dependencies should not be considered a serioussmell but it is a good sign that the program warned the user
59
Figure 53 Shared Persistency at ldquoPassenger databaserdquo
Weekend Modularity The last detected smell is called Weakened Modularity Itis reported for the Business Process ldquoArriving at airportrdquo with modularity ratio ofaround 0615 and the Application Collaboration ldquoBoarding and departure controlsystemrdquo with modularity ratio of around 066 Additionally the Application Compo-nent ldquoAirline administration supportrdquo is classified as that smell with a ratio of 044This Weakened Modularity can be perceived in Figure 54 on page 56 where theAirline administration support realizes three Application Services but overall nineother elements are related This leads to the low modularity ratio such that thiscomponent should be examined further
60
Figure 54 Weekend Modularity at ldquoAirline administration supportrdquo
61
Chapter 6
Discussion
This section covers applying the SmellCull mechanism into software developmentThe discussion is started by establishing the mechanismrsquos role in a software develop-ment environment followed by sections discussing the expectations set for the first im-plementation of the mechanism The expectations are made from a software projectrsquosperspective and cover foreseeable benefits and challenges
61 Application in EA Development
The SmellCull mechanism provides the identification of Enterprise Architecture debtby processing and capturing relevant observations Processing requires that the mech-anism is made available in Enterprise Architecture components where observationsabout the EA model are made These observations are processed based on an Detec-tor List(DL) and automatically identified by the SmellCull mechanism This thesisreport and project serves as the integration point for further Enterprise Architecturedebt identification approaches and provides information to existing EA debt and evenEnterprise Model components
In iterative and incremental software development the implementation process re-lies onto previous iterations having completed their requirements as further additionsand modifications are directly based onto them [26] This makes the implementationprocess very sensitive to deviations in the assumed implementation state Every sin-gle change could be very tough to handle As we have predicted that the SmellCullmechanism has the ability to mark off the EA debt in the beginning of implementa-tion levelSo it prevents developers and the process from making mistakes
Other software development components emergent to technical debt related obser-vations are dependent onto the used software development method The Scrummethodrsquos Sprint review[73] is an example of a software development practice theSmellCull mechanism is expected to support Here developers who are familiar with
62
the SmellCull mechanism take part in a process where a software product or a sub-product is assessed against currently active requirements As deviations are foundthe developers catch them in the form of EA debt
The SmellCull mechanism identify the EA debt according to the Detector List(DL)and captured observations The DL can be used to integrate further evaluation anddecision approaches from the EA Debt Management Framework(EADMF) Concur-rently the received EA debt provides valuable information to existing EA modelcomponents For example the Sprint planning practice of the Scrum method[73] mayapply the DL in defining new backlog items large Detector Item(DI) entries mayrequire their own backlog items while the decomposition of new requirements intobacklog entries is further defined by reviewing the amount of EA debt indicated bythe DL for this implementation area
Enterprise architecture debt analysis is the application of property assessment crite-ria on enterprise architecture models For instance one investigated property mightbe the information security of an information system and a criterion for assessmentof this property might be ldquoIf the architectural model of the enterprise features anintrusion detection system then this indicates a higher level of information securitythan if there is no such system[36]rdquo Criteria and properties such as these may be ex-tracted from scientific theories or from empirical measurements In current practiceemployed criteria are rarely expressed explicitly If they are they are frequently bothvague and ambiguous in nature making enterprise architecture analysis problematicwith respect to both precision and accuracy
What constitutes a ldquogoodrdquo enterprise architecture model has thus far not been clearlydefined This is due to the fact that the ldquogoodnessrdquo of the model is not an inherentproperty but contingent on the purpose the model is intended to fill ie what kindof analyses it will be subjected to Johnson and Ekstedt (2007)[36] Lindstrom et al(2006)[45] For instance if one seeks to employ an enterprise architecture model forevaluating the interoperability of an information system the information requiredfrom the model differs radically from the case when the model is used to evaluate thesystemrsquos usability
62 Benefits
SmellCull is giving feedback to the structure of Enterprise Architecture Model En-terprise Architecture Model implementations are complex hierarchical and intercon-nected structures EA debt that resides in them has similar characteristics TheSmellCull mechanism captures EA debt as Detector Items(DI) DIs are formed as aset of SmellCull elements for which the SmellCull mechanism automatically indicatesthe propagation paths This structured form allows to track EA debt during con-
63
tinued development but also to apply various assessment approaches to the differentlevels of the acquired hierarchy
SmellCull are able to recognize EA debt at the beginning of implementation level Byprojecting EA debt observations onto the implementation level the SmellCull mecha-nism ensures that development is conducted while aware of EA debtrsquos presence Thisallows developers to avoid unintentionally increasing the value of EA debt throughdependencies to affected areas or to efficiently decrease its value by resolving EA debtin areas where development is currently conducted
SmellCull makes continued use of higher level EA debt management approaches pos-sible The structure is designed to be able to produce the EA Debt List for EA modelThe extensions that the SmellCull mechanism introduces allows to modify this listduring continued development This makes the tool reliant management approachesapplicable to the development at any given time
SmellCull brings out EA debts by following human-made observations through cod-ing In addition to EA Developers being fully aware of all active requirements anddevelopment conventions they can provide additional reasoning for their observa-tions This will ensure that information regarding the captured EA debt of a projectwill be more accurate and well defined Improvements based onto this informationshould be very effective
Finally the benefits of SmellCull have also been empirically analyzed Clearly Theempirical evaluation indicated that the debt identification provided by SmellCull aremeaningful
64
Chapter 7
Conclusion
To conclude this thesis the answers of the research questions are written in section71 that were set in the start of this thesis and some ideas are provided as entry pointsfor future research in section 72
71 Summary
In this thesis the SmellCull tool has been introduced for identifying EA debt thatwill be extended with Enterprise Architecture Smells The SmellCull mechanism hasbeen designed to be extensible with different EA Models It improves the quality ofEA Models such that that the benefits can be transferred to the more holistic causeof EAThis includes increased awareness and in general easier processes of discoveringdeficits in modelrsquos designs
The first research question that was under focus to investigate the architecture ofthe tool and check the feasibility to future extensions We have created a customisedmodel where different type of model property can be added So that this tool willbe extensible unlimited model integration Also for exchanging data between auto-created model to customised model another layer has been used Thus this tool keepsits robustness by broadening the architecture
The second research question was regarding the input format of the tool The tooltakes two input one input as Model another input as Validator The empirical datafor smells identification can be used as input in different format eg XML Excel Thefirst input provides control over the component and that the data that is returned isall used Another input as XSD-File has to check the schema to verify against
For third Model transformation has been done between auto generated model andCustomised model thus having the same attributes relations and operations to thecustomised model Here we have used Semantics for model transformationStill more
65
techniques could be followed for Model transformation
The tool is able to (i) automatically detect EA Smells and (ii) point out which modelas well as property is responsible for the Smells
Yes any RESTful web service can be integrated with the tool We used Springframework to handle the HTTP GETPOST requests The APIs will take a modelamp validator identify some EA smells in the model and respond accordingly
72 Future Work
SmellCull mechanism concept has been presented and the tool is still under develop-ment Accommodating this the SmellCull tool is expected to reach its first majorversion during the last quarter of 2020 This will enable us to improve validate andextend both the mechanism and the tool
721 Mechanism Improvement amp Validation
SmellCull can be designed more sophisticated and universal way so that it can beintegrated into continuous integration continuous development(CICD) pipelines Byextending the metrics and algorithms for the detection supplementary EA Smells canbecome automatically detectable Blob Divergent Change Deficient EncapsulationFunctional Decomposition Refused Bequest could be the upcoming Anti-pattern asthe detection strategies might be similar to the existing Anti-pattern
Furthermore different approaches for detection can be tested like genetic or evo-lutionary algorithms So-called Rule Mining algorithms working with Rule Cards([59] [57]) could be used to approximate useful metric Even Process Mining canbe used to gain further information on Business Processes which could help developrefined approaches Further Interrelationship between business function and organi-zation might be useful to find complex anti-pattern This type of relationship can befound through the chain of command
To propagate the use of SmellCull we could start a separate research Albeit in early-stages our research on applying link structure algorithms especially the PageRankalgorithm[58] has provided us with promising results when used to value and indicatemost crucial implementation elements for the accumulation of EA debt As we haveintended this tool as aproductivity enhancement for industrial settings we intend tofurther improve and validate the SmellCull mechanism in such environments
To investigate in the future development of this project is what could be the targetgroup of such tool Obviously SmellCull is a tool that targets the Enterprise Archi-
66
tects of a company But if there is no Enterprise Architecture department within thecompany the tool can still be useful
722 Extending the Range of Supported Techniques
In addition to covering a range of implementation techniques we will be working onmaking the mechanism cross-compatible with other EA debt identification and as-sessment tools By working together with mature EA debt identification and SQALEmethod[44] we expect to increase the accuracy and range of produced informationthus making EA debt management more robust with the SmellCull mechanism
The customised model can be improved by extending the levels or adding more levelconsidering behavior characteristics service or elements This means more subclassesinheriting current properties such as attributes relationships constraints and behav-ior of the parent class is also existent in the child class inherited from its parent Eachchild class can also have its own properties Here the entities that will be used forthe modeling of the companyrsquos systems will be described The reason that not allthe entities are described is that the reader should not be forced to understand allthe entities since not all of them are used For further studies one can look up thefollowing sources
Again different types of model can be included as input by using new transformationrules and more features can be added on the customised model In particular forcustomised model one can analyze the structural dependencies between the entitiesof classes ie attributes and methods in order to build for each entitythe entity setie the set of methods using it Also Enterprise meta modeling methodsndashcombiningstakeholder-oriented and causality-based approach can be applied to develop the cus-tomized model[40]
Our User Interface(UI) can also be improved by integrating more elements such asInput Controls Navigation Components Informational Components Containers forproviding more user friendly environment
67
68
A Code Smell Website
Figure 1 Code Smell Website page 1 of 4
69
Figure 2 Code Smell Website page 2 of 4
70
Figure 3 Code Smell Website page 3 of 4
71
Figure 4 Code Smell Website page 4 of 4
72
73
B EA Smell Website
Figure 5 EA Smell Website page 1 of 4
74
Figure 6 EA Smell Website page 2 of 4
75
Figure 7 EA Smell Website page 3 of 4
76
Figure 8 EA Smell Website page 4 of 4
77
References
[1] Ieee standard glossary of software engineering terminology IEEE Std 61012-1990 pages 1ndash84 1990
[2] G Frey A Shvets and M Pavlov Antipatterns httpssourcemakingcom
antipatterns March 2019
[3] M Abbes F Khomh Y Gueheneuc and G Antoniol An empirical study of theimpact of two antipatterns blob and spaghetti code on program comprehensionIn 2011 15th European Conference on Software Maintenance and Reengineeringpages 181ndash190 2011
[4] Mashel Albarak and Rami Bahsoon Prioritizing technical debt in databasenormalization using portfolio theory and data quality metrics In Proceedings ofthe 2018 International Conference on Technical Debt TechDebt rsquo18 page 31ndash40New York NY USA 2018 Association for Computing Machinery
[5] Peter Alexander Simon Hacks Jurgen Jung Horst Lichter Ulrike Steffens andOmer Uludag A framework for managing enterprise architecture debts-outlineand research directions
[6] Ashraf Anwar A review of rup (rational unified process) International Journalof Software Engineering (IJSE) 5(2)12ndash19 2014
[7] Innovative Architects Sdlc models methodologies httpswww
innovativearchitectscomKnowledgeCenterbasic-IT-systems
8-SDLC-modelsaspx May 2020
[8] R S Arnold Software restructuring Proceedings of the IEEE 77(4)607ndash6171989
[9] J Atwood Code smells httpsblogcodinghorrorcomcode-smells
[10] I Avazpour T Pitakrat L Grunske and J Grundy Recommendation systemsin software engineering Dimensions and metrics for evaluating recommendationsystems pages 245ndash273 2014
78
[11] Donald Bell Uml basics The sequence diagram httpwwwcsunedu
~twang380SlidesSequenceDiagrampdf February 2004
[12] Johannes Bohnet and Jurgen Dollner Monitoring code quality and developmentactivity by software maps In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 9ndash16 New York NY USA 2011 Associationfor Computing Machinery
[13] W H Brown AntiPatterns Refactoring Software Architectures and Projectsin Crisis pages 4 14 16ndash18 John Wiley amp Sons New York NY USA firstedition 1998
[14] Rafael Carlos Daniel C Amaral and Mauro Caetano Framework for continuousagile technology roadmap updating Innovation amp Management Review 2018
[15] Codegiant Software development life cycle mdash the ul-timate guide [2020] httpsblogcodegiantio
software-development-life-cycle-the-ultimate-guide-2020-153d17bb20fb2020
[16] Ward Cunningham The wycash portfolio management system SIGPLAN OOPSMess 4(2)29ndash30 December 1992
[17] Rayan Dasoriya Significance of software development models InternationalJournal of Advanced Research in Computer Science 8(8) 2017
[18] William Delone and Ephraim McLean The delone and mclean model of in-formation systems success A ten-year update J of Management InformationSystems 199ndash30 04 2003
[19] Christof Ebert and Jozef De Man Effectively utilizing project product andprocess knowledge Information and Software Technology 50(6)579 ndash 594 2008
[20] M Ekstedt U Franke P Johnson R Lagerstrom T Sommestad J Ullbergand M Buschle A tool for enterprise architecture analysis of maintainabilityIn 2009 13th European Conference on Software Maintenance and Reengineeringpages 327ndash328 2009
[21] Harleen K Flora and Swati V Chande A systematic study on agile softwaredevelopment methodologies and practices International Journal of ComputerScience and Information Technologies 5(3)3626ndash3637 2014
[22] Lucas Borante Foganholi Rogerio Eduardo Garcia Danilo Medeiros ElerRonaldo Celso Messias Correia and Celso Olivete Junior Supporting techni-cal debt cataloging with td-tracker tool Adv Soft Eng 2015 January 2015
79
[23] Apache Software Foundation Apache maven project httpsmavenapacheorg October 2020
[24] Martin Fowler Refactoring Improving the design of existing code page 256 082002
[25] Fabian Gampfer Andreas Jurgens Markus Muller and Rudiger BuchkremerPast current and future trends in enterprise architecturemdasha view beyond thehorizon Computers in Industry 10070 ndash 84 2018
[26] T Gilb and G Weinberg Software metrics Winthrop Publishers 1999
[27] Oscar Gonzalez-Rojas Alexandra Lopez and Dario Correal Multilevel com-plexity measurement in enterprise architecture models International Journal ofComputer Integrated Manufacturing 30(12)1280ndash1300 2017
[28] Yuepu Guo and Carolyn Seaman A portfolio approach to technical debt man-agement In Proceedings of the 2nd Workshop on Managing Technical DebtMTD rsquo11 page 31ndash34 New York NY USA 2011 Association for ComputingMachinery
[29] S Hacks H Hofert J Salentin Y C Yeong and H Lichter Towards the defini-tion of enterprise architecture debts In 2019 IEEE 23rd International EnterpriseDistributed Object Computing Workshop (EDOCW) pages 9ndash16 2019
[30] Robert Half 6 basic sdlc methodologies Which one isbest httpswwwroberthalfcomaublogemployers
6-basic-sdlc-methodologies-which-one-best December 2019
[31] J Holvitie and V Leppanen Debtflag Technical debt management with adevelopment environment integrated tool In 2013 4th International Workshopon Managing Technical Debt (MTD) pages 20ndash27 2013
[32] DM Hutton Clean code A handbook of agile software craftsmanship Kyber-netes 2009
[33] W Probandt J Becker and O Vering Principles of proper modeling page 9Heidelberg Berlin Springer-Verlag 2012
[34] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[35] Mahdi Javanmard and Maryam Alian Comparison between agile and traditionalsoftware development methodologies Fen Bilimleri Dergisi (CFD) 36(3) 2015
[36] Pontus Johnson Robert Lagerstrom Per Narman and Marten Simonsson En-terprise architecture analysis with extended influence diagrams InformationSystems Frontiers 9(2-3)163ndash180 2007
80
[37] F Khomh S Vaucher Y Gueheneuc and H Sahraoui A bayesian approach forthe detection of code and design smells In 2009 Ninth International Conferenceon Quality Software pages 305ndash314 2009
[38] Foutse Khomh Massimiliano Di Penta Yann-Gael Gueheneuc and GiulianoAntoniol An exploratory study of the impact of antipatterns on class change-and fault-proneness Empirical Softw Engg 17(3)243ndash275 June 2012
[39] Philippe Kruchten Robert L Nord and Ipek Ozkaya Technical debt Frommetaphor to theory and practice IEEE Softw 29(6)18ndash21 November 2012
[40] Robert Lagerstrom Jan Saat and Franke Enterprise meta modeling methodsndash combining a stakeholder-oriented and a causality-based approach In TerryHalpin John Krogstie and Nurcan editors Enterprise Business-Process andInformation Systems Modeling pages 381ndash393 Berlin Heidelberg 2009 SpringerBerlin Heidelberg
[41] Matthias Lange Jan Mendling and Jan Recker A comprehensive ea benefitrealization modelndashan exploratory study Proceedings of the Annual Hawaii In-ternational Conference on System Sciences pages 4230ndash4239 01 2012
[42] Matthias Lange Jan Mendling and Jan Recker An empirical analysis of thefactors and measures of enterprise architecture management success EuropeanJournal of Information Systems 25(5)411ndash431 2016
[43] Juan De Lara Esther Guerra and Jesus Sanchez Cuadrado When and how touse multilevel modelling ACM Trans Softw Eng Methodol 24(2) December2014
[44] Jean-Louis Letouzey The sqale method for evaluating technical debt In 2012Third International Workshop on Managing Technical Debt (MTD) pages 31ndash36IEEE 2012
[45] Asa Lindstrom Pontus Johnson Erik Johansson Mathias Ekstedt and MartenSimonsson A survey on cio concerns-do enterprise architecture frameworks sup-port them Information Systems Frontiers 8(2)81ndash90 2006
[46] Martin Lippert and Stephen Roock Refactoring in large software projects per-forming complex restructurings successfully John Wiley amp Sons 2006
[47] VICTOR M The ultimate guide to the sdlc httpsultimatesdlccom
project-management-method-sdlc 2020
[48] Mika V Mantyla and Casper Lassenius Subjective evaluation of software evolv-ability using code smells An empirical study Empirical Software Engineering11(3)395ndash431 2006
81
[49] Daniel Moody A multi-level architecture for representing enterprise data modelsIn David W Embley and Robert C Goldstein editors Conceptual Modeling mdashER rsquo97 pages 184ndash197 Berlin Heidelberg 1997 Springer Berlin Heidelberg
[50] Nabil Mohammed Ali Munassar and A Govardhan A comparison between fivemodels of software engineering International Journal of Computer Science Issues(IJCSI) 7(5)94 2010
[51] Dinnie Muslihat Agile methodology an overview httpsmediumcom
zenkitagile-methodology-an-overview-7c7e3b398c3d March 2018
[52] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[53] Mathieu Nayrolles Naouel Moha and Petko Valtchev Improving soa antipat-terns detection in service based systems by mining execution traces In 2013 20thWorking Conference on Reverse Engineering (WCRE) pages 321ndash330 IEEE2013
[54] Dag H Olsen Enterprise architecture management challenges in the norwegianhealth sector Procedia Comput Sci 121(C)637ndash645 January 2017
[55] Nikhil Oswa Technical debt Identify measure and monitor httpsarxiv
orgpdf191012816pdf
[56] Ali Ouni Raula Gaikovina Kula Marouane Kessentini and Katsuro Inoue Webservice antipatterns detection using genetic programming In Proceedings of the2015 Annual Conference on Genetic and Evolutionary Computation pages 1351ndash1358 2015
[57] Ali Ouni Marouane Kessentini Katsuro Inoue and Mel O Cinneide Search-based web service antipatterns detection IEEE Transactions on Services Com-puting 10(4)603ndash617 2015
[58] Lawrence Page Sergey Brin Rajeev Motwani and Terry Winograd The pager-ank citation ranking Bringing order to the web Technical report StanfordInfoLab 1999
[59] Francis Palma Naouel Moha Guy Tremblay and Yann-Gael Gueheneuc Specifi-cation and detection of soa antipatterns in web services In European Conferenceon Software Architecture pages 58ndash73 Springer 2014
[60] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
82
[61] Francis Palma and Naouel Mohay A study on the taxonomy of service antipat-terns In 2015 IEEE 2nd International Workshop on Patterns Promotion andAnti-patterns Prevention (PPAP) pages 5ndash8 IEEE 2015
[62] Fabio Palomba Gabriele Bavota Massimiliano Di Penta Fausto Fasano RoccoOliveto and Andrea De Lucia On the diffuseness and the impact on maintain-ability of code smells a large scale empirical investigation Empirical SoftwareEngineering 23(3)1188ndash1221 aug 2017
[63] Fabio Palomba Andrea De Lucia Gabriele Bavota and Rocco Oliveto Anti-pattern detection Methods challenges and open issues In Advances in Com-puters volume 95 pages 201ndash238 Elsevier 2014
[64] J Pitschke Good Models How the quality of business models can be defined andmeasured 2011
[65] B Ribeiro-Neto R Baeza-Yates Modern Information Retrieval pages 73ndash96Addison-Wesley 1999
[66] Vanshika Rastogi Software development life cycle models-comparison conse-quences International Journal of Computer Science and Information Technolo-gies 6(1)168ndash172 2015
[67] Ratnmala and RavalHaresh Rathod Comparative Study of Various ProcessModel in Software Development International Journal of Computer Applica-tions 8216ndash19 November 2013
[68] Will Reviewer-Tracz Refactoring for software design smells Managing technicaldebt by girish suryanarayana ganesh samarthyam and tushar sharma ACMSIGSOFT Software Engineering Notes 40(6)36ndash36 2015
[69] Linda Rising and Norman S Janoff The scrum software development process forsmall teams IEEE software 17(4)26ndash32 2000
[70] Lagerstrom Robert and Pontus Johnson Using architectural models to predictthe maintainability of enterprise systems pages 248ndash252 05 2008
[71] Johannes Salentin and Simon Hacks Towards a catalog of enterprise architecturesmells 03 2020
[72] Jaap Schekkerman How to survive in the jungle of Enterprise ArchitectureFrameworks pages 1613 Lemma USA second edition 2004
[73] Ken Schwaber Scrum development process In Jeff Sutherland Cory CasanaveJoaquin Miller Philip Patel and Glenn Hollowell editors Business Object De-sign and Implementation pages 117ndash134 London 1997 Springer London
83
[74] Carolyn Seaman Yuepu Guo Nico Zazworka Forrest Shull Clemente IzurietaYuanfang Cai and Antonio Vetro Using technical debt data in decision makingPotential decision approaches pages 45ndash48 06 2012
[75] Tushar Sharma Marios Fragkoulis and Diomidis Spinellis Does your configu-ration code smell In 2016 IEEEACM 13th Working Conference on MiningSoftware Repositories (MSR) pages 189ndash200 IEEE 2016
[76] A Shvets Refactoring clean your code In 2015 IEEE 2nd InternationalWorkshop on Patterns Promotion and Anti-patterns Prevention (PPAP) pages14ndash17 23 12 March 2014-2019
[77] Dag I K Sjoberg Aiko Yamashita Bente Anda Audris Mockus and Tore DybaQuantifying the effect of code smells on maintenance effort IEEE Trans SoftwEng 39(8)1144ndash1156 August 2013
[78] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[79] Davide Taibi and Valentina Lenarduzzi On the definition of microservice badsmells IEEE software 35(3)56ndash62 2018
[80] Felix Timm Simon Hacks Felix Thiede and Daniel Hintzpeter Towards aquality framework for enterprise architecture models 12 2017
[81] Edith Tom AybuKe Aurum and Richard Vidgen An exploration of technicaldebt J Syst Softw 86(6)1498ndash1516 June 2013
[82] Edith Tom Aybuke Aurum and Richard Vidgen An exploration of technicaldebt Journal of Systems and Software 86(6)1498 ndash 1516 2013
[83] Venu Gopal Balijepally Torgeir Dings Sridhar Nerur and Nils Brede MoeA decade of agile methodologies Towards explaining agile software develop-ment International Journal of Computer Science and Information Technologies851213ndash1221 February 2012
[84] J Ullberg R Lagerstrom and P Johnson A framework for service interoper-ability analysis using enterprise architecture models In 2008 IEEE InternationalConference on Services Computing volume 2 pages 99ndash107 2008
[85] W C Wake Refactoring Workbook pages 14ndash1722 AddisonWesley LongmanPublishing Co Boston MA USA first edition 2003
[86] Tiexin Wang Sebastien Truptil and Frederick Benaben An automatic model-to-model mapping and transformation methodology to serve model-based systemsengineering Information Systems and e-Business Management 15(2)323ndash3762017
84
[87] R Winter and R Fischer Essential layers artifacts and dependencies of en-terprise architecture In 2006 10th IEEE International Enterprise DistributedObject Computing Conference Workshops (EDOCWrsquo06) pages 30ndash30 2006
[88] A Yamashita and L Moonen Do code smells reflect important maintainabilityaspects In 2012 28th IEEE International Conference on Software Maintenance(ICSM) pages 306ndash315 2012
[89] Aiko Yamashita and Leon Moonen Exploring the impact of inter-smell relationson software maintainability An empirical study In Proceedings of the 2013 In-ternational Conference on Software Engineering ICSE rsquo13 page 682ndash691 IEEEPress 2013
[90] Simon Hacks Yoon Chow and Horst Lichter Prioritization of EA Debts Facilitat-ing Portfolio Theory 7th International Workshop on Quantitative Approaches toSoftware Quality in conjunction with the 26th Asia-Pacific Software EngineeringConference (APSEC 2019) December 2019
[91] J A Zachman A framework for information systems architecture IBM SystemsJournal 26(3)276ndash292 1987
[92] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
[93] Nico Zazworka Carolyn Seaman and Forrest Shull Prioritizing design debtinvestment opportunities In Proceedings of the 2nd Workshop on ManagingTechnical Debt MTD rsquo11 page 39ndash42 New York NY USA 2011 Associationfor Computing Machinery
85
wwwkthse
TRITA-EECS-EX-2020908
