An analysis system for mobile applications MVC software architectures

Dragos Dobrean 0000-0001-7521-7552, Laura Diosan 0000-0002-6339-1622Computer Science Department, Babes Bolyai University, Cluj Napoca, Romania

{dobrean, lauras}@cs.ubbcluj.ro

Keywords: mobile applications software architecture; automatic static analysis; model view controller

Abstract: Mobile applications are software systems that are highly used by all modern people; a vast majority of thoseare intricate systems. Due to their increase in complexity, the architectural pattern used plays a significantrole in their lifecycle. Architectural patterns can not be enforced on a codebase without the aid of an externaltool; with this idea in mind, the current paper describes a novel technique for an automatically analysis ofModel View Controller mobile application codebases from an architectural point of view. The analysis takesinto account the constraints imposed by this layered architecture and offers insightful metrics regarding thearchitectural health of the codebase, while also highlighting the architectural issues. Both open source andprivate codebases have been analysed by the proposed approach and the results indicate an average accuracyof 89.6% of the evaluation process.

1 Introduction

Nowadays there are many companies which arebuilt around their mobile applications (Instagram,Whatsapp, Uber, etc.) which have large teams of peo-ple working on those projects. These kind of projectsneed to be maintained over a long period of time andthey need to be flexible to new Software Develop-ment Kit (SDK) and hardware features. In order fora project to be extensible, maintainable and for morepeople to be able to work on it in parallel it needsto have a software architecture which allows it. Mo-bile applications usually use presentational softwarearchitectures and generally all of the architecturalflavours used descend from Model View Controller(MVC) (Fowler, 2002; Reenskaug, 2003). Each plat-form uses a flavour of MVC as their ”default” archi-tecture, alongside those, other architectural patternshave been coined such as Model View Presenter (Po-tel, 1996), Model View View Model (Garofalo, 2011),or View Interactor Presenter Entity Router (Mutual-Mobile, 2014) in order to provide extra flexibility andtestability of those applications.

Many of the codebases do not respect the imposedarchitecture for various reasons. One of the reasonsis the fact that the developers working on the projectsdo not have the right experience and skill set whichresult into architectural smells such as Brick Func-tionality Overloading, Scattered Parasitic Functional-ity, Logical Coupling or Ambiguous Interfaces (Le

et al., 2015). Another reason for architectural ero-sion is the transition from one architectural pattern toanother without doing it all over the codebase and allthe refactoring needed.

An architectural pattern, which can impose thecode to be written in a predefined way or to imposeany strict boundaries can not be created without anexternal system which periodically checks it. Takinginto consideration the architectural problems whichappear on the mobile platforms, their increasing pop-ularity and the fact that most problems are caused bydevelopers which do not use the pattern correctly andnot by requirements or other external factors, we havedeveloped a system which statically checks if a mo-bile codebase is valid from an architectural point ofview, while also highlighting the issues if those ex-ist. Moreover, this system also provides valuable in-formation which can be used by the management tocheck the architectural health of a codebase and tosee tangible results of the refactoring phases.

The novelty of the proposed system is given bythe usage of information from the mobile SDKs ratherthan relying strictly on the information extracted fromthe codebase as in other approaches (Garcia et al.,2013; Corazza et al., 2016; Boaye Belle, 2016). In ad-dition, it uses a simple formalisation of the architec-tural rules rather than complex specifications (Rum-baugh et al., 2004),(Hussain, 2013), which makes itsimply understandable even by less experienced prac-titioners. Furthermore, by using the proposed system,

the architectural pressure points can be easily iden-tified and this can be done early in the developmentphase by using it in a CI/CD pipeline.

The following section talks about MVC and itsparticularities. Section 2 analyses the MVC archi-tecture and provides a way of detecting violation ofits implementation. In section 3 we present the re-sult of the validation experiments conducted on pri-vate and open-source iOS projects with the proposedmethod. The final section, states our conclusions andsome ideas that could be tackled in future work.

2 Software architecture checkersystem

The proposed system analyses a mobile applica-tion based on the composing components, it clustersthem in categories based on the implemented archi-tecture of the codebase and constructs the topologicalstructure of the codebase, a dependency graph. Af-ter the graph has been constructed, the relationshipsbetween its composing components are analysed andarchitectural issues are highlighted (Fig 1). By com-ponent we mean one different element of the follow-ing kind: class, struct, protocol, enumeration.

Figure 1: Software architecture checker system phases

2.1 Detection

The detection phase of the system takes a mobilecodebase and analyses its components. It detects allthe classes, protocols, structs and enums together withall their instance properties and methods (both privateand public). The result of this detection is an analysisdocument in which we have stored all the informationregarding the codebase, paths of the codebase com-ponents, their properties (methods, variables and thenames and types of those) together with the size ofthe files. All of this information is encoded in a struc-tured file (eg. JSON, XML or other type) which willbe used by the extracting phase.

2.2 Extraction

There are many approaches for extracting an archi-tecture from a codebase (Garcia et al., 2013; Corazzaet al., 2016; Belle et al., 2013), or for specifying it(Rumbaugh et al., 2004; Hussain, 2013). However,

none of those approaches are designed specifically formobile codebases and they are too complex for thepurpose of our study.

In order to extract the architecture of the codebasewe analyse the file produced by the detection phase.We are constructing the topological structure of theimplemented architecture based on the information inthat file. The topology is represented by a directedgraph in which every node corresponds to a compo-nent and has the following informations: name, type,kind (class / struct / protocol / enum name), inheritedtype, instance and class variables (name and type), in-stance and class methods (together with parametersnames and types), path.

The edges between nodes represent the links inthe code between two components. Unlike a clas-sic graph, in the architectural topological structurewe can have multiple links between two nodes: aclass has multiple references to another class; eachof them is translated into an edge, allowing to specif-ically highlight all the individual codebase issues.

2.3 Categorisation

The most sensitive step in the analysis process is thecategorisation one: the previously defined compo-nents need to be assigned in a certain category. Previ-ous work has been done in the area of software archi-tecture clusterisation and it was analysed from variousperspectives: modules (Huang and Liu, 2016; Paixaoet al., 2018), components (Ramırez et al., 2018), lay-ers (Belle et al., 2013).

For the purpose of our research we are interestedin the layered one. The components of a codebasecan be distributed on abstract layers by following twostrategies: the responsability-based strategy and thereuse-based strategy. In our MVC-context, the firststrategy is implemented. MVC has also been anal-ysed in (Xu and Liang, 2014b; Chen et al., 2014):an evolutionary algorithm optimises the mapping be-tween the class responsibilities and the pattern roles.In our case, we define several heuristics, specific tomobile applications, that have to be respected by suchmapping. Our proposed solution is a deterministicone; the search space is smaller as we are focusingon the codebase alone. In (Mariani et al., 2016) thelayered architectures are analysed, but the focus is onchanging the codebase for avoiding the layered viola-tions. They do not analyse the architectural style usednor do they specifically focus on mobile platforms.To the best of our knowledge, the architectural stylewas analysed only in (Sarkar et al., 2009) and (Maf-fort et al., 2013), but these approaches are not mobileoriented.

Regarding the architecture conformance, the liter-ature describes two main techniques: reflexion mod-els and domain-specific languages that express the de-pendency rules. The reflexion models compare the in-tended architecture expressed as a high-level modelcreated by the architect with the implemented oneextracted from the source code and expressed as aconcrete model. In general, the high-level model re-quires a set of refinements in order to identify thearchitecture violations (Koschke, 2013). In (Maffortet al., 2013) a lightweight specification of the high-level model is proposed in order to mine the structuraland historical architectural patterns. Our approachis somehow similar to Maffort’s approach, but is fo-cus on mobile applications and integrates informationfrom the mobile SDKs rather than relying strictly onthe information extracted from the codebase. Thedomain-specific languages help the architects to de-fined the intended architecture by using various con-straints expressed in a customised and elaborated syn-tax (Terra and Valente, 2009). The constraints we pro-posed to be used can be easily defined and mined inthe checker system.

We propose a novel mobile-inspired approach: thecategories represent the layers of the analysed archi-tectural pattern. In the case of the current researchthose are Model, View and Controller. We can lever-age the fact that the mobile applications use certainSDKs for displaying information on the screen. Theinteraction with the user, both input and output, is ma-nipulated by SDKs provided by the creators of mobileOperating Systems. With this idea in mind, we pro-pose the following heuristics for deciding which com-ponent fits in which layer:

• All Controller layer items should inherit fromController classes defined in the used SDK

• All View layer items should inherit from a UIcomponent from the used SDK

• All the remaining items are treated as Model layeritems

2.4 Analysis

MVC has been extensively analysed by practition-ers (Orlov, 2015; Kocsis, 2018; DeLong, 2017) andacademia (La and Kim, 2010; Garofalo, 2011; Olssonet al., 2018) on mobile applications and other soft-ware systems. The potential issues highlighted suchas massive view controllers or violation of single re-sponsibility principle (DeLong, 2017) constitute thebase for our research and represent the architecturalissues we want to highlight early in the developmentphase. Therefore, the last phase of the processing is

the analysis of the dependency graph generated bythe extraction phase, correlated to the clusterisationon abstract layers. In this study, we are analysingwhether or not one of the rules which dictate the MVCpattern are violated. Every rule violation is detectedand highlighted. After this step we can say whether ornot the codebase respects the MVC architecture andwhich are the pressure points in the codebase, whatshould be refactored and which are the componentsresponsible for those violations.

The dependency relation between two layers, de-fined as two sets A and B, can be formalised as a setL⊆ A×B as follows: LB

A = {l = (a,b)|a∈ A∧b∈ B}.Note that a link is different to a coupling. The link isunidirectional, while the coupling is bidirectional.

After all the components have been split intothe three categories (Model, View, Controller), eachcomponent is checked against all the other compo-nents from the other two layers for finding dependen-cies. The dependencies which are forbidden are high-lighted and presented to the end user of the system.

In the classic MVC architecture all the depen-dencies are allowed except for the one between theModel and the Controller. This rule can be ex-pressed formally by defining LController

Model , the relationsof Model’s components to components of the Con-troller layer: LController

Model = {l = (m,c)|m ∈ Model ∧(c ∈ Controller)}. In order for the application torespect the classic MVC dependencies, LOther

View = /0

should be true. Based on the MVC flavour used theallowed dependencies rules can be different.

3 Evaluation

The aim of the analysis is to inspect whether or notthe MVC architecture is respected in the codebasesof commercially available mobile applications usingour proposed system. The rest of the paper focuseson the iOS platform and on Swift codebases; how-ever, the same principles can be applied to other mo-bile platforms (Android, Window Mobile) and evenon some other ranges of presentational applicationssuch as desktop applications. The main differencesbetween iOS and other platforms would be the nam-ing of the components and frameworks used. In thispart of the study the focus was on answering the fol-lowing research questions:RQ1 - How effective is the proposed categorisationmethod compared to manual inspections?RQ2 - What is the topological structure of mobilecodebases using the proposed approach?RQ3 - Do mobile codebases respect the architecturalrules?

3.1 Methodology

Since we inspect iOS codebases, for the validationand analysis of the proposed system we have used therules of Apple’s flavour of MVC (Apple, 2012b):Controller: LCC

VC = {l = (vc,cc)|vc ∈ ViewControl-lers ∧ cc ∈ CoordinatingControllers} = /0 meaningthat ViewControllers should not depend on other Co-ordinator controllersView: LOther

View = {l = (v,o)|v ∈ View∧ (o ∈ Control-ler∨ o ∈ Model)} = /0 meaning that all componentsin the View layer should only depend on componentswithin the same layerModel: LOther

Model = {l = (m,o)|m ∈Model∧ (o ∈Con-troller∨o∈View)}= /0 meaning that all componentsin the Model layer should only depend on componentswithin the same layer

A codebase respects Apple’s flavour of MVC (Ap-ple, 2012b) when all the above rules are respected.Mobile applications do not always use the Coordina-tor layer as this is a fairly unknown to the vast ma-jority of developers, that is why our analysis has twocategorisation approaches:

3.1.1 MVC Approach (SimpleCateg)

Analysing the most common MVC implementation(classic MVC) by identifying the View objects, theController (without coordinators - meaning that thecode from navigating from a ViewController to an-other should reside in a child of an SDK defined Con-troller object) and all the other items were treated asModels.

Layers & components The Controller layer doesnot contain any Coordinating objects. The heuristicsinvolved in this approach are:

H1 Controllers←CategorisationVCs(Comps.)

H2 Views←CategorisationViews(Comps.\Controllers)

H3 Models←Comps.\ (Controllers∪Views)

Dependencies rules used for validationR1 LOthers

View = /0 – all View components depend only on otherView components

R2 LOthersModel = /0 – all Model components depend only on

other Model components

3.1.2 MVC with Coordinators approach(CoordCateg)

Analysing the MVC with coordinating objects inplace. Every items which dealt with UIKit definedController object was marked as a coordinator object.

We have also taken all the objects that deal with thosecoordinator objects, and put them in the same cate-gory as well — Coordinating controllers.

Layers & components The Controller layer con-tains Coordinating objects. The heuristics involvedin this approach are:

H4 Controllers←CategorisationVCsAndCCs(Comps.)

H2 Views←CategorisationViews(Comps.\Controllers)

H3 Models←Comps.\ (Controllers∪Views)

Dependencies rulesR1 LOthers

View = /0 – all View components depend only on otherView components

R2 LOthersModel = /0 – all Model components depend only on

other Model components

R3 LCCsVCs = /0 – all ViewController components should not

depend on Coordinator components

3.2 Evaluation metrics

With both approaches we were interested in the samemetrics. Our evaluation is two folded: validation ofthe categorisation process and analysis of how the ar-chitectural rules are respected or not.

In the validation stage, to measure the effective-ness of the categorisation, we compare the resultsfrom manual inspection (that acts as ground truth) tothose of our methods. Three metrics are of interestin this validation: accuracy, precision and recall. Inthe case of multi-class classification problems (in ourcase we have a problem with 3 classes) the accuracymetric could be misleading since it does not take intoaccount is the analysed data is balanced or not (all theclasses have the same number of examples). Precisionand recall are better-suited metrics.

In the analysis stage, the number of components(#Comp) from each abstract layer, the percentage ofthe Model, View and Controller components from theoverall total and how many MVC rules were invali-dated in the codebase (based on the analysed flavour)are computed.

We were also interested in the number of depen-dencies within a layer (#IntDepends), as well as in thenumber of external dependencies (#ExtDepends) of alayer. The #IntDepends are represented by links in thearchitectural topology of the codebase which are donebetween components which reside in the same layer.#ExtDepends represent the links between the compo-nents of a layer and components which reside withinthe other two layers of MVC. Moreover, the #Com-pleteExtDepends include the external links relative toMVC layers and the links with other SDKs and third

party libraries defined types, as well as Swift prede-fined types (such as String, Int) or codebase definedtypes (such as closures). These numbers denote thelayers which are highly coupled with other layers orlibraries and identifying those can ease the refactoringprocess by highlighting to the developers the itemswhich are too complex and represent an architecturalpressure point in the system, and revalidate the layersconstructed correctly which are loosely coupled andself contained.

Another important metric is the number of differ-ent external links (#DiffExtDepend) — the numberof different codebase components on which a certaincomponent depends. The components with a largeamount of different dependent items which violate thearchitectural rules are problematic and represent ar-chitectural pressure points in the analysed codebase.

Note that architectural change metrics (e.g.architecture-to-architecture, MoJoFM, cluster-to-cluster (Le et al., 2015)) can not be used in orderto establish which rules are violated, since theconceptual/intended architectures of the analysedsystems are unknown.

3.3 Data

In order to test our system we have used some small,medium and large sized private and open-source iOSprojects written in Swift. All the external librarieswere ignored as well as their codebase are not rele-vant for the analysed application. In other words, wehave analysed the Swift files defined in the project,and none of the external ones or the ones written inanother programming language.

We have analysed 5 applications: mobile Webbrowser - Firefox (Mozilla, 2018), information -Wikipedia (Wikimedia, 2018), cryptocurrency wallet- Trust (Trust, 2018), e-commerce application - pri-vate and multiplayer game - private.

Table 1: Short description of investigated applicationsApplication Blank Comment CodeFirefox 23392 18648 100111Wikipedia 6933 1473 35640Trust 4772 3809 23919E-Commerce 7861 3169 20525Game 839 331 2113

As can be seen in Table 1. we have analyseddifferent sized codebase. Blank, comment and codecolumns refer to the type of the text written in a line.In order for the categorisation process to be accurate,we have identified all the iOS SDK defined ViewCon-troller and View components types defined in the iOSSDK, there are 12 different ViewController items and40 View ones.

3.4 Results

RQ1 - How effective is the proposed categori-sation method compared to manual inspections?The first evaluation done was for the categorisationphase. We have manually analysed each applicationand placed each one of its components in one of theModel, View, Controller layers. After creating theground truth, the system was ran over the studied ap-plications and the results were compared against thebaseline. Table 2 presents our findings for each of theapplications using the precision, recall and accuracymetrics.

Table 2: The effectiveness of the categorisation process interms of Accuracy, Precision and Recall.

Appr Applic Model View Ctrl AccP R P R P RSimple Firefox 96 99 100 98 98 71 95Coord. Firefox 96 77 100 96 46 90 82Simple Wiki 76 99 100 57 98 89 87Coord. Wiki 72 73 100 57 73 95 78Simple Trust 78 98 100 67 100 37 82Coord. Trust 83 88 100 67 64 70 82Simple E-comm 75 100 100 100 100 54 84Coord. E-comm 96 78 100 96 78 100 89Simple Game 100 100 100 100 100 100 100Coord. Game 100 100 100 100 100 100 100

We start the validation by an important metric, theaccuracy, which denotes how many components werecorrectly identified for all the analysed layers. Our ex-periment shown that by using the SimpleCateg, with-out the coordinators detection, the proposed systemwas able to correctly categorise the components inlayers with an average accuracy of 89.6% on all ofthe analysed codebases, while CoordCateg achievedan average accuracy of 86.2%.

An interesting finding is that in the case of the ap-plications where the Coordinator concept was consis-tently used throughout the code (Trust, E-Commerce)the results were better for the CoordCateg approach,however on the other applications where this conceptwas not used, the results were worst.

The detection of the Coordinator components isheavily influenced by the way the navigation from oneViewController to another is implemented in the ap-plication. If this is scattered all around the codebaseand is not extracted in custom components (Coordi-nators) the detection process will be affected. Whilebuilding the ground truth, we have prioritised inheri-tance over the links between components – meaningthat if a component inherits from a View element buthas dependencies to other Controller components wehave marked it as a View component – as we had noway of knowing what the developers intended.

In the categorisation phase of the CoordCateg ap-proach we are interested in the behaviour while de-

tecting the Coordinators. It is more important to high-light that a component has the behaviour of a Coordi-nator than to leave it as a View or Model component.Due to how the code was written and the usage ofexternal libraries of View elements, the accuracy forthe CoordCateg approach is worst in the case of theFirefox and Wikipedia apps. The difference in the ac-curacy indicates that in the codebase there is a differ-ence between the behaviour and the intended type ofa component, which highlights an architectural mis-conception.

In the case of the simplest application (from an ar-chitectural point of view), both approaches correctlyidentified the components with an accuracy of 100%.From Precision’s point of view, the best classifiedcomponent is the View one (in both approaches) andno false positive are identified for this layer. From Re-call’s point of view, the best classified component bythe first approach is the Model, while by the secondapproach is the Controller – such result is somehowcorrelated with H4, the improved heuristic focused onController layer. In several cases (ECommerce andGame) a perfect recall is obtained indicating that thesystem produces no false negatives.

If we compare the results of the first approachwith those of the second approach we observe howthe second approach improves the Controller’s recallbecause it is able to identify more types of compo-nents that should belong to this layer (not only thatare pure View Controllers).

In the same time the Controller’s precision and theView’s recall decrease (their are some View compo-nents that, due to the filtering order, are labelled asCoordinator objects, breaking the mention metrics).Furthermore, the Model’s recall decreases since someModel’s components are labelled as Coordinating ob-jects.

The Model’s precision increases in some cases(e.g. Trust and ECommerce applications) becausethere are fewer false positive cases: some Coordi-nating objects, labelled as Model by the first ap-proach, are labelled as Controller by the second ap-proach. However, the Model’s precision decreaseswhen the second approach labelled as Coordinatorssome Model’s components (that manipulate View-Controllers), similar to the View’s components wrongclassified.

The View’s precision is constant and reach themaximum, this being a good sign that the proposedsystem is able to correct recognise all View’s compo-nents. The View’s recall if affected by the usage ofexternal libraries for UI components (e.g. Wiki case).

As a first conclusion, our system is able of cate-gorising the components on the right layers.

RQ2 - What is the topological structure of mobilecodebases using the proposed approach? Fig. 2presents clusters composed from three categories(Model, View, Controller) showing the number ofdifferent components (#Comp) / #IntDepends — thenumber of internal dependencies for each cluster. Thefirst columns from each application refer to the Sim-pleCateg, while the second columns denote the Co-ordCateg approach. As can be seen from the analysisand the sizes of the codebase, a smaller codebase canhave more components even if it has fewer number oflines. This is due to the granularity of the architec-ture. Usually a higher granularity indicates a betterarchitecture.

Figure 2: Codebase components, distribution of compo-nents on layers

The #IntDepends are increasing in the case of theCoordCateg approach for the Controller layer and de-creasing or keeping their status for the other two lay-ers. This decrease of internal dependencies in theView and Model happens due to the migration of var-ious components in the Controller layer as Coordinat-ing items; the remaining items have a higher degreeof cohesion among them.

Tables 3 and 4 summarise the analysis of the sep-aration on each one of the codebases, both #ExtDe-pends and #DiffExtDepend are presented. Theitems highlighted in red represent the dependencieswhich violate the MVC rules. While links Model—Controller and View—Controller should exits, thoseshould be done trough interfaces and the Model andView should have no direct knowledge about the Con-troller; that is why those items were highlighted aswell.

As can be seen from the two approaches, Coord-Categ produces more accurate results and it does nothave any negative side effects on codebases which donot use coordinators at all (Game). The shift fromModel and View to more Controller components canbe seen in the #CompleteExtDepends section of Ta-bles 3 and 4, as well as in the Fig. 2, the Controller

Table 3: Codebase analysis - SimpleCateg approach#ExtDepends / #DiffExtDependDependency Firefox Wiki Trust E-comm GameView - Model 21/9 7/3 21/14 72/27 1/1View - Controller 3/1 - - 2/1 -Model - View 203/19 99/11 49/11 122/11 1/1Model - Controller 161/11 55/8 146/23 560/69 -Controller - Model 152/41 78/35 74/37 290/62 38/6Controller - View 403/46 545/35 146/30 637/47 42/13#CompleteExtDependsModel 3001 1393 1745 2018 111View 598 146 163 274 19Controller 1615 2212 496 1702 188

Table 4: Codebase analysis - CoordCateg approach#ExtDepends / #DiffExtDependDependency Firefox Wiki Trust E-comm GameView - Model 21/9 7/3 21/14 63/25 1/1View - Controller 3/1 - - 2/1 -Model - View 126/14 91/11 35/11 103/8 1/1Model - Controller - - - - -Controller - Model 257/41 73/32 264/66 431/62 38/6Controller - View 448/46 576/35 161/31 674/49 42/13VC - CC 50/9 8/3 - 49/8 -#CompleteExtDependsModel 2129 957 1228 846 111View 569 146 163 241 19Controller 2646 2672 1193 2569 188

has more items, while the Model and sometimes theView has fewer.

RQ3 - Do mobile codebases respect the architec-tural rules? Our approach intends to highlight thearchitectural problems and to provide meaningful in-sights regarding the codebase. To this aim we analyseMVC specific validation rules over different types ofdependencies found in the codebase. Note that thepurpose of this study was not to compare the extractedarchitectural topology against a reference one (alsoknown in literature as the conceptual architecture)since it not available for the analysed systems. Hence,in Tables 3 and 4 can be seen that the validation rulesR1 and R2 are violated in both approaches. One rea-son for this can be the fact that developers tend to re-spect the classic MVC dependencies rules and ignorethe Apple’s flavour of MVC (Apple, 2012b) depen-dency rules. However, in the CoordCateg approach(Table 4) the rule violation is more mildly as we havefewer invalidations. This amelioration could be a con-sequence of the improved heuristic used for identify-ing Controller layer components (H4).

In the CoordCateg approach, as can be seen in Ta-ble 4 the rule R3 is violated in 3 of the 5 analysedcodebases; the Game codebase does not use Coordi-nating controllers, while in the case of Trust applica-tion the dependency rule is respected. In the case ofapplications where the Coordinating controllers arewell understood, they are usually correctly imple-mented. However in other cases where this sub-layer

appears as a side effect of the complexity in the Con-troller layer, they are inadequately constructed.

As can be seen in both Tables 3 and 4, the ma-jority of the architectural problems are encounteredbetween the Model and the other layers. This showsthat the Model layer is usually wrongly constructedand it is not clear for developers what should residein there. Moreover the analysis also shows that whilemobile projects are split in composing layers, MVCtries to be followed, the dependencies between thoselayers are not correctly constructed.

3.5 Threats to validity

Internal validity - In the case of Coordinating Con-trollers detection there might be mismatches betweenthe purpose given by the developer to that compo-nent and our categorisation process. This shift fromModel and View layer might not always be valid assome components were intended to reside in thoselayers, but they simply are wrongly coupled withViewControllers. In addition to this this wrong cat-egorisation heavily affects the analysis phase. More-over the usage of third party libraries for the UI com-ponents heavily impacts the categorisation processwhich drastically impacts the rest of the analysis asthose are not covered by our proposed heuristics. Fur-thermore the analysis was conducted on the iOS plat-form using the Swift language, for other platformswhich use languages which support multiple inheri-tance some of the heuristics might not apply.External validity - The current study focuses onMVC and its flavours on the most popular mobileplatforms. By using the current approach, custom ar-chitectural patterns can not be analysed, in order toovercome this issue the categorisation process shouldbe enriched with more layers and improving the clus-tering capabilities.Conclusion validity - The study can be ran on moreapplications to strengthen our findings. Additionalmetrics can be used for analysing the dependencies inorder to give relevant insights regarding the stability,testability and extensibility of the analysed codebase.

4 Conclusions

Architectural patterns can not enforce their ruleson developers. In the domain of software architec-tures, the builders — developers, can cross architec-tural boundaries fairly easy; that is why an externalsystem is needed for enforcing the chosen architec-tural pattern. Our research provides a distinct tech-nique for analysing the mobile codebases, without the

need for using complex ADL languages and valida-tion systems. The proposed method uses the mobileSDKs particularities for constructing an easy to useand understand system which can come in the aid ofmobile developers. Discovering the root and sourcesof the technical debt and highlighting the architec-tural issues of the codebase benefits both developersas well as management, as they can see the architec-tural health of the codebase.

The fact that the codebase is split in well definedcategories represent just part of the benefits obtainedby respecting an architectural pattern. The correct de-pendencies between layers is what offers all the otherarchitectural benefits (flexibility, testability, maintain-ability, etc.) and it is more important than just cate-gorising the components. Our results show that thosedependencies are not correctly constructed and thereis a need for an architectural checker system on mo-bile platforms for imposing architectural patterns.

As future steps, we plan to extend the systemto work with custom defined software architectures,such that it can analyse multiple type of projects. Thesystem can also be integrated into a CI/CD pipeline,highlighting architectural issues early in the develop-ment phase before the code goes into the final prod-uct.

REFERENCES

Ameller, D. and Franch, X. (2011). Ontology-based archi-tectural knowledge representation: structural elementsmodule. In CAiSE, pp. 296–301. Springer.

Apple (2012a). Controller. link.Apple (2012b). Model-view-controller. link.Belle, A. B. et al. (2013). The layered architecture revisited:

Is it an optimization problem? In SEKE, pp. 344–349.Boaye Belle, A. (2016). Recovering software layers

from object oriented systems: a formalization as anoptimization problem. PhD thesis, Ecole de technolo-gie superieure.

Chen, X. et al. (2014). A replicated experiment on archi-tecture pattern recommendation based on quality re-quirements. In ICSESS, pp. 32–36. Citeseer.

Corazza, A. et al. (2016). Weighing lexical information forsoftware clustering in the context of architecture re-covery. Empirical Software Engineering, 21(1):72–103.

DeLong, D. (2017). A better MVC. link.Fowler, M. (2002). Patterns of enterprise application

architecture. Addison-Wesley Longman PublishingCo., Inc.

Garcia, J. et al. (2013). A comparative analysis of softwarearchitecture recovery techniques. In ICASE, pp. 486–496. IEEE Press.

Garofalo, R. (2011). Building enterprise applicationswith Windows Presentation Foundation and the ModelView View Model Pattern. Microsoft Press.

Huang, J. and Liu, J. (2016). A similarity-based modular-ization quality measure for software module cluster-ing problems. Information Sciences, 342:96–110.

Hussain, S. (2013). Investigating architecture descriptionlanguages (ADLs) a systematic literature review. PhDthesis, Linkapings Universitet.

Kocsis, K. (2018). Architectural patterns, MVC, MVVM:What is the hype all about? link.

Koschke, R. (2013). Incremental reflexion analysis. Journalof Software: Evolution and Process, 25(6):601–637.

La, H. J. and Kim, S. D. (2010). Balanced mvc architecturefor developing service-based mobile applications. InICEBE, pp. 292–299. IEEE.

Le, D. M. et al. (2015). An empirical study of architecturalchange in open-source software systems. In IEEEMSR, pp. 235–245.

Maffort, C. et al. (2013). Mining architectural patterns usingassociation rules. In SEKE, 2013, pp. 375–380.

Mariani, T. et al. (2016). Preserving architectural styles inthe search based design of software product line archi-tectures. J. of Systems and Software, 115:157–173.

Mozilla (2018). Firefox iOS application. link.MutualMobile (2014). Meet VIPER: Clean architecture for

iOS apps. link.Olsson, T. et al. (2018). Towards improved initial map-

ping in semi automatic clustering. In ECSA, page 51.ACM.

Orlov, B. (2015). iOS architecture patterns: DemystifyingMVC, MVP, MVVM and VIPER. link.

Paixao, M. et al. (2018). An empirical study of cohesionand coupling: Balancing optimization and disruption.IEEE TEC, 22(3):394–414.

Potel, M. (1996). MVP: Model-View-Presenter the taligentprogramming model for C++ and Java. Taligent Inc,page 20.

Ramırez, A. et al. (2018). Interactive multi-objectiveevolutionary optimization of software architectures.Information Sciences.

Reenskaug, T. (2003). The model-view-controller (MVC)its past and present. University of Oslo Draft.

Rumbaugh, J. et al. (2004). Unified modeling languagereference manual, the. Pearson Higher Education.

Sarkar, S. et al. (2009). Discovery of architectural lay-ers and measurement of layering violations in sourcecode. J. of Systems and Software, 82(11):1891–1905.

Terra, R. and Valente, M. T. (2009). A dependency con-straint language to manage object-oriented softwarearchitectures. Software: Practice and Experience,39(12):1073–1094.

Trust (2018). Trust wallet iOS application. link.Wikimedia (2018). Wikipedia ios application. link.Xu, Y. and Liang, P. (2014b). A cooperative coevolution

approach to automate pattern-based software architec-tural synthesis. IJSEKE, 24(10):1387–1411.

Zhang, M. (2018). Photoshop coming to the iPad. link.