Journal of Object Technology | RESEARCH ARTICLE

Evolution of Bad Smells in LabVIEW Graphical ModelsSaheed Popoola Xin Zhao and Jeff Gray

University of Alabama Tuscaloosa USA

ABSTRACT Bad smells often indicate potential problems in software which may lead to long-term challenges and expensivemaintenance efforts Although bad smells often occur in source code bad smells also exist in representations of designdescriptions and models We have observed that many users of graphical modeling environments (eg LabVIEW) are systemsengineers who may not be aware of core software engineering techniques such as refactoring of bad smells Systems engineersoften focus on implementation correctness and may be unaware of how their designs affect long-term maintenance propertiesthat may increase design smells There exists a large body of research focused on analysing bad smells embedded in thesource code of textual languages but there has been limited research on bad smells in systems models of graphical languagesIn this paper we present a semi-automated approach for extracting design smells across versions of LabVIEW graphical modelsthrough user-defined queries We describe example queries that highlight the emergence of design smells that we discoveredfrom posts in the LabVIEW userrsquos forum We then demonstrate the use of the example queries in understanding the evolutionof seven bad smells we found in 81 LabVIEW models stored in 10 GitHub repositories We analyze the evolution of thesesmells in order to understand the prevalence and introduction of bad smells as well as the relationship between bad smells andthe structural changes made to the models Our results show that all of the models contain instances of at least one type ofbad smell and the number of smells fluctuates as the size of a model increases Furthermore the majority of the structuralchanges across different versions of LabVIEW models involve the addition of new elements with a corresponding increase inthe presence of design smells This paper summarizes the need for better analysis of design smells in systems models andsuggests an approach that may assist in improving the structure and quality of systems models developed in LabVIEW

KEYWORDS LabVIEW models bad smells user queries

1 IntroductionThe design of software systems may contain flaws that nega-tively affect quality and maintainability These flaws (knownas ldquobad smellsrdquo) are generally considered undesirable in thepractice of software engineering because they tend to reduce theoverall quality of the software increase the complexity of futurerefactoring activities decrease the understanding of the softwarecode and reduce the reusability features of system components(Roberts et al 1999) Bad smells are not bugs (ie they do notprevent the program from functioning correctly) but suggest

JOT reference formatSaheed Popoola Xin Zhao and Jeff Gray Evolution of Bad Smells inLabVIEW Graphical Models Journal of Object Technology Vol 20 No 12021 Licensed under Attribution - No Derivatives 40 International (CCBY-ND 40) httpdxdoiorg105381jot2021201a1

potential weaknesses in design that may increase the risk ofbugs in the future Studies have shown that code with many badsmells takes 32 longer to debug and causes more frustrationto programmers (Zaman et al 2012) Therefore bad smellsrepresent a major challenge to the quality and maintenance oflarge and complex software systems

Software repositories usually provide a rich source of his-torical data related to software analysis and quality evaluationdue to the version histories of software systems preserved inthese repositories Historical data in a software repository alsodepicts the evolution of software design and the various refactor-ing activities that have been performed over the life cycle of asystem Hence it is not surprising that much research has beendevoted to extracting manipulating and analysing the data em-bedded in repositories in order to support software maintenancedetect and refactor bad software designs and conduct empirical

An AITO publication

validation of new research techniques (Robbes et al 2017)Bad smells may be introduced at the initial version of a sys-

tem and propagated through subsequent versions while newsmells may also be introduced at any version of the system(Olbrich et al 2009) Therefore as a system ages the instancesof bad smells embedded in the system continue to evolve andmay lead to larger and more complex architectural problemsPast research resolved bad smells via data extracted from publicsoftware repositories in textual programming languages (Chatzi-georgiou amp Manakos 2014 Tahmid et al 2016) This bodyof research is very important in understanding and analysingthe evolution of bad smells in software However the major-ity of data stored in software repositories and the approachesdeveloped to manipulate them have targeted the source codeof text-based languages There is a considerably less amountof software engineering research on graphical languages ingeneral related to bad smells in system evolution

Graphical models have been used for many decades in soft-ware engineering to capture concepts within the problem spaceand abstract external complexities such as infrastructure depen-dencies or programming environments that simplify softwaredesign concepts (Ludewig 2003) The graphical nature of mod-els also aids in visualizing different aspects of a system therebyeasing the learning curve for developing new models to cap-ture essential system properties As a result paradigms suchas Model-Based Systems Engineering (MBSE) have been de-veloped to promote the use of models as first-class artifacts forvirtually any software development task such as implementationtesting and analysis The analysis of systems models is veryimportant because a model primarily abstracts the design con-cepts of a system to be developed therefore design problemssuch as bad smells may emerge in the model used to representa system Unfortunately there is limited research on the evolu-tionary analysis of bad smells in graphical models and systemsdeveloped via graphical environments

The Laboratory Virtual Instrument Engineering Workbench(LabVIEW) by National Instruments is an extensible systemsmodeling platform that is currently used by hundreds of thou-sands of users in more than 15000 companies all over the world(Services nd Falcon 2017) LabVIEW provides a graphicalprogramming environment for developing test instruments andsoftware systems that require fast access to hardware data How-ever despite the extensive industrial and academic usage ofthis platform in developing complex and sometimes criticalsystems LabVIEW systems models rarely gain attention insoftware engineering research Furthermore the platform ismostly used by traditional engineers (eg systems engineersor mechanical engineers) who may not be familiar with basicsoftware engineering concepts thereby increasing the possi-bility of bad software designs and high maintenance effort Aprevious study has shown that LabVIEW developers often tendto prioritize correctness over other properties that may affect themaintainability of the software over a period of time (Chambersamp Scaffidi 2013)

This paper introduces an approach for analysing the evolutionof bad smells in LabVIEW graphical models via user-definedqueries We focus our work on LabVIEW because it has a large

number of industrial and academic users In this paper wedescribe an approach for mining LabVIEW models in softwarerepositories via user-defined queries to detect and analyse thepresence of four of the design smells identified by end users in(Zhao amp Gray 2019) We extend a tool named Hawk (Barmpis ampKolovos 2014)(Garciacutea-Domiacutenguez et al 2019) to query historiesof LabVIEW models stored in GitHub repositories The querieswere used to extract and analyse the evolution of bad smellsthat were present in the version history of 81 models across 10GitHub repositories1 The analysis of the query results show thatall repositories contain at least one type of smell and most smellsare often introduced in the initial version of the repositoriesFurthermore the number of smell instances in these modelstends to increase steadily for a period and then decrease eventhough the size of the models continues to increase throughoutthe systemrsquos life cycle The contributions of this paper include

1 We propose a semi-automated approach to detect badsmells in graphical languages via user-defined queries

2 We investigate the presence of seven bad smells in 10LabVIEW GitHub projects

3 We also present the evolutionary analysis of the persistenceof these bad smells across the life cycle of the LabVIEWmodels in these projects

The remainder of the paper is organized as follows Section2 offers an overview of bad smells across graphical modelsand text-based programs while Section 3 provides an overviewof the LabVIEW modelling platform Section 4 discusses theresearch questions that motivate our study Section 5 givesa detailed description of the seven bad smells that have beenselected for analysis in this paper while Section 6 introducesthe Hawk framework for mining repositories of graphical mod-els We also discuss how Hawk queries were generated forthe selected bad smells Section 7 presents the evaluation ofthe queries on 81 models in 10 LabVIEW repositories and theanalysis of the results returned by the queries across the versionhistory of the models The section also presents answers tothe research questions that motivate this research Section 8mentions the threats that may challenge the results analysed inSection 7 while Section 9 discusses related work and highlightshow our work extends existing literature Finally Section 10offers our concluding comments and also outlines our futureplans to enhance the evolution analysis of graphical models

2 Bad Smells in Systems Models and Text-Based Programs

The concept of bad smells evolved from the research on de-sign patterns Gamma et al (Gamma et al 1995) categoricallypresented a catalog of succinct solutions to commonly occur-ring design problems Their 23 design patterns assist softwaredevelopers in creating more flexible elegant and reusable de-signs without having to rediscover the design solutions Opdykeformalized refactoring to support the design evolution and

1 httpbitlyLMeta

2 Popoola et al

reuse of object-oriented application frameworks in his PhDdissertation (Opdyke 1992) The refactorings are defined to bebehavior preserving and remove bad smells in Object-OrientedProgramming (OOP) provided that their preconditions are metAlthough bad smells have been studied thoroughly in the con-text of text-based programming environments over the past twodecades the examination of bad smells in graphical models isparticularly limited

Bad smells in systems models (also known as ldquomodelsmellsrdquo) indicate bad designs that usually correspond to a deeperproblem in a systems model Bad smells in systems models arerelated to bad smells in OOP but there also exist significant dif-ferences between bad smells in OOP and bad smells in systemsmodels OOP has a correspondence with textual programminglanguage (such as Java C++ and Python) but systems modelslargely adopt graphical representations (such as Simulink andLabVIEW models) In textual languages source code oftendefines the executable order of a computation in graphical lan-guages a communication medium (such as wires in LabVIEWand Simulink systems models) for passing data between dif-ferent blocks is always required This distinction leads to badsmell summarization differences For example UnorganizedWires is a bad smell reported by LabVIEW end-users (Zhao ampGray 2019) It refers to the use of unorganized wires to connectdifferent parts of models thus making the model hard to readand understand However no similar bad smells are discussedin existing literature in the context of OOP Bad smells in OOPand systems models also share some commonalities For exam-ple Long Parameter List is a bad smell mentioned in existingliterature that occurs when a method includes too many formalparameters A similar bad smell is found in LabVIEW systemsmodels (Chambers amp Scaffidi 2013) A deeper analysis of badsmells in systems models has the potential to provide engineerswith more insight on how to improve the maintainability andreliability of systems models

3 Overview of LabVIEW

LabVIEW is a systems modelling tool for managing model-based systems engineering processes The tool provides agraphical language named G that can be used to model anddevelop applications that require fast access to hardware andtest data (Johnson 1997) The tool also provides support formany third-party hardware and software vendors as well as theability to extend the tool to develop custom user interfaces andcommands

LabVIEW models are composed of Virtual Instruments (VIs)that are often stored in separate files similar to how classes arehandled in OOP A VI can run on its own or it can be groupedtogether with other VIs to provide a common functionalityA VI is composed of two main components a front-panelthat captures the front-end or user interface of the applicationand a block-diagram that stores the main program logic of theapplication A third component named icon is used to storeexternal images used in the model Figure 1 shows the front-panel and block-diagram of a VI that adds two inputs and returnsa result as output to the user LabVIEW models were originally

stored in binary format which makes it hard to analyse usingautomated tools However the recent LabVIEW NXG versionstores models in XML making it more amenable to read andanalyse by external tools This study focuses on LabVIEWprograms developed in the new NXG version Listing 1 showshow the VI in Figure 1 is persisted as files Lines 2 to 7 containinformation about ldquoinput 1rdquo terminal lines 2 to 4 are used tocapture the input value while lines 5 to 7 are used to capturethe name of the terminal (ie input 1) Similarly Lines 8 to 13represent information about ldquoinput 2rdquo terminal while lines 14 to19 represent the output terminal Line 20 represents the additionoperation while lines 2122 and 23 represent the differentwires that links input 1 input 2 and output terminals with theldquoadditionrdquo node

1 ltBlockDiagram Id=12gt2 ltDataAccessor Id=16 Label=19gt3 ltTerminal DataType=Double Direction=4 Output gt5 ltDataAccessor gt6 ltNodeLabel AttachedTo=16 Id=19gt7 ltpTextgtInput 1ltpTextgt8 ltNodeLabel gt9 ltDataAccessor Id=21 Label=24 gt

10 ltTerminal DataType=Double Direction=11 Outputgt12 ltDataAccessor gt13 ltNodeLabel AttachedTo=21 Id=24gt14 ltpTextgtInput 2ltpTextgt15 ltNodeLabel gt16 ltDataAccessor Id=26 Label=29 gt17 ltTerminal DataType=Double Direction=18 Inputgt19 ltDataAccessor gt20 ltNodeLabel AttachedTo=26 Id=29gt21 ltpTextgtOutput ltpTextgt22 ltNodeLabel gt23 ltAdd Id=30 Terminals=o=33 c0t0v=31 c1t0v

=32 gt24 ltWire Id=31 Joints=N(16 Value)| N(3025 c0t0v) gt26 ltWire Id=32 Joints=N(21 Value)| N(3027 c1t0v) gt28 ltWire Id=33 Joints=N(30o)|N(26 Value) gt29 ltBlockDiagram gt

Listing 1 Simplified Block Diagram Part of a VI file

4 Research QuestionsWe analysed the evolution of bad smells in LabVIEW modelsOur aim was to discover the prevalence of smells in LabVIEWat what point in time the smells are introduced and the codechanges that introduce increase or decrease the smells in themodels Specifically our study answers the following threeresearch questions

RQ1 How prevalent are bad smells in LabVIEW models Cham-bers et al (Chambers amp Scaffidi 2013) conducted a studyto show that LabVIEW developers tend to prioritize thecorrectness of the software to be developed over otherproperties that may affect the maintainability of the soft-ware over a period of time This suggests that LabVIEWmodels may be a ripe source for bad smells However

Evolution of Bad Smells in LabVIEW Graphical Models 3

Figure 1 A Front Panel and Block Diagram to Add Two Numbers

we do not know of any study that validates this assump-tion Our study aims to discover the prevalence of severalselected bad smells in LabVIEW models stored in openrepositories

RQ2 When are bad smells introduced in LabVIEW modelsFowler (Roberts et al 1999) proposes that bad smells insoftware programs are often introduced due to the evolu-tion and maintenance activities that are performed through-out the programrsquos life cycle This may indicate that badsmells are often introduced at later stages of the softwaredevelopment cycle However Tufano et al (Tufano etal 2015) conducted a study of 5 types of smells in over200 open source Android Apache and Eclipse projectsTheir results show that most smells are present in the firstversion of a program Therefore the results from bothFowler (Roberts et al 1999) and Tufano et al (Tufanoet al 2015) suggest the bad smells may creep into soft-ware at various stages of development We do not knowof a similar study that has been conducted to investigatewhen smells are introduced in LabVIEW models or graph-ical models in general Our study aims to discover thecommon trends of how bad smells are first introduced inLabVIEW repositories

RQ3 What is the relationship between the bad smells and struc-tural changes made to a model This phase of the researchwork aims to unravel the set of changes to a model that ledto the introduction of new smells in the model and the setof changes that led to an increase reduction or removalof bad smells in the model This is a first step to generatea set of best practices for writing programs with minimalsmells as well as the anti-patterns that should be avoideddue to the likelihood of introducing new smells to a model

To answer the research questions mentioned above we imple-mented the following approaches

1 We selected 10 repositories from GitHub These reposito-ries were selected by searching for the keyword labviewnxg in GitHub and the repositories were checked to con-

tain at least one LabVIEW NXG file We were able togather 10 repositories

2 We extended the Hawk tool (see Section 6) to supportquerying the evolution history of LabVIEW models Thismakes it easy to extract the history of LabVIEW models inselected GitHub repositories

3 We constructed seven Hawk queries to detect instances ofseven smells in LabVIEW The execution of the queriesin Hawk will produce the evolution history of smells inselected models

4 We manually analysed the results of the queries to answerthe research questions discussed above

5 Smell SelectionMany smells in LabVIEW have been identified in previousworks Chambers and Scaffidi (Chambers amp Scaffidi 2013) iden-tified smells based on an interview conducted with experiencedLabVIEW developers while Carcao et al (Carccedilao 2014)(Carccedilaoet al 2014) identified more smells based on the rate of energyconsumed when LabVIEW programs are executed Howeverthese smells are more related to performance issues and do notcover a wider range of developerrsquos experience (eg a new de-veloper may find some tasks challenging and it may be trivialto an expert) Due to the number of smells that can be detectedit is practically infeasible for us to analyse all possible smellsthat can be detected in LabVIEW models In this paper weanalysed selected smells that have been extracted from posts inLabVIEW discussion forums (Zhao amp Gray 2019) Due to theopen-nature of these online forums various issues are discussedby developers with a wide-range of expertise hence we believethat the smells captured in this way are representative both interms of the needs of LabVIEW developers and the categoryof programs involved Moreover statistical results show thatend-users are deeply interested in reviewing and replying toposts related to LabVIEW model smells From 2000 to 2019the average review and reply per post are 119739 and 594respectively while the average review and reply related to badsmell posts are 135602 and 1555 respectively

4 Popoola et al

Zhao and Gray (Zhao amp Gray 2019) identified 15 bad smellswhile Chambers and Scaffidi (Chambers amp Scaffidi 2013) iden-tified 13 smells Six of these smells were reported in bothpapers thereby resulting in a net total of 22 smells We se-lected seven of the smells for this study due to the limited costand time required to effectively analyse all of the 22 smellsThe seven smells studied in this paper are 1) Large Variables2) No Wait in a Loop 3) Build Array in a Loop 4) ExcessiveProperty Nodes 5) String Concatenation in Loop 6) Multi-ple Nested Loops and 7) Deeply Nested Subsystem HierarchyThese smells are selected for the following reasons

1 Ease of validation The selected smells have well-definedcriteria for affirming the presence of the specific smell inthe set of models For example the smell No Wait in a Loopmeans that the absence of a Wait element in any loop isconsidered a smell Hence we only need to check whetherany of the loops in a set of models does not contain theWait element in order to affirm the presence of the smell inthe models

2 Scope of inclusion The selected smells cover two majorperspectives of a VI performance and structure Perfor-mance relates to the model execution such as the time amodel needs to run and the memory a program consumeswhile executing No Wait in a Loop is likely to causesynchronization issues (Chambers amp Scaffidi 2013) whilethe Build Array in a Loop smell and the String Concate-nation in a Loop smell slows the programrsquos performanceand causes memory issues (Chambers amp Scaffidi 2013)Multiple Nested Loops occurs when loop structures areembedded in another loop structure This increases themodelrsquos structural complexity reduces readability andmay also lead to other control and performance issuesLarge Variables refers to the use of many variables in amodel Excessive Property Nodes refers to the usage ofProperty Nodes element in a model and Deeply NestedSubsystem Hierarchy refers to when a VI contains toomany levels of subVIs These three smells increase thestructural complexity of a model thus affecting the modelunderstandability

3 Level of granularity The selected smells represent dif-ferent levels of granularity within a VI Large Variablesexamines the usage of the most basic data unit that a VIuses Four smells No Wait in a Loop Build Array in aLoop Excessive Property Nodes and String Concatena-tion in Loop focus on the investigation of smells relatedto a single nodestructure in a systems model MultipleNested Loops explores multiple nodesstructures withina VI that may affect system models and Deeply NestedSubsystem Hierarchy analyses bad smells from a structuralaspect The inspection of these smells at different gran-ularity levels helps us to better understand bad smells insystems models and observe how different smells evolveover time

The following paragraphs provide a detailed description ofeach of the seven smells in our study

A Large Variables

Large Variables refers to the adoption of too many localvariables in a model In LabVIEW a local variable is usedto communicate between structures within one moduleIt is similar to formal parameters of a method in OOPOverusing local variables such as using them to avoidlong wires across a block diagram or using them insteadof data flow can lead to several maintenance issues Localvariables make copies of data buffers If users adopt toomany local variables to transfer large amounts of data fromone place on the block diagram to another more memoryis consumed and may result in slower execution

B No Wait in a Loop

This bad smell often occurs during a data acquisition pro-gram In a general object-oriented program when a ForLoop or a While Loop finishes executing one iteration itmay immediately begin running the next The frequencyof one iteration is usually not considered In LabVIEWmodeling however it is often beneficial to control howoften a loop executes For example in industrial practiceit is important to mark the data acquisition rate If userswant to acquire data in a loop they would need a methodto control the frequency of the data acquisition In thissituation a pause in a loop is necessary Timing a loop alsoallows the processor time to complete other tasks such asupdating and responding to the user interface

C Build Array in a Loop

This bad smell refers to the construction of an array insidea loop structure When an array node is inside a loop everytime the loop starts a new iteration a new copy of the arrayis constructed This process leads to increased memoryconsumption and may cause severe performance issues

D Excessive Property Nodes

The purpose of Property Nodes in a LabVIEW model isto programmatically control the properties of a front-endor user interface object such as color visibility positionnumeric and display format For example users couldchange the color of a dial to go through blue green and redas its numerical value increases However the excessiveusage of Property Nodes can introduce several issues inLabVIEW models One of the issues is that there is a lot ofoverhead with Property Nodes Each Property Node accesswill result in a context switch to the UI thread which willslow model execution

E String Concatenation in a Loop

This bad smell as the name suggests refers to the adoptionof String Concatenation structure inside the body of aloop Chambers and Scaffidi (Chambers amp Scaffidi 2013)first identified this bad smell from their interview withLabVIEW experts They affirm that the implementationof String Concatenation structure in the body of a loopcauses slow performance and memory issues

Evolution of Bad Smells in LabVIEW Graphical Models 5

F Multiple Nested LoopsThis bad smell refers to placing loop structures inside thebody of another loop structure Multiple Nested Loops areconsidered as a negative programming practice because itrsquosexecution is time consuming and it also increases the pro-gramrsquos complexity Many works have been conductedto solve deeply nested problems (Quillereacute et al 2000)(Karunaratne et al 2018) Similar to other programminglanguages the use of nested loops in LabVIEW modelsreduces readability (Chambers amp Scaffidi 2013) and some-times can be problematic when introducing other structuresin the outer loop Due to the nature that LabVIEW is adataflow-driven programming paradigm the introductionof other structures inside of a loop may contribute to con-trol and design issues Many discussions related to theseissues are found in the LabVIEW discussion forum (suchas nested loop control2 design issue3)

G Deeply Nested Subsystem HierarchyModularity is essential for software systems and is sup-ported by decoupling software into reusable units (Exman2014) In LabVIEW modularity is achieved by the adop-tion of a SubVI A SubVI is the same as a VI and it alsocontains a front panel and a block diagram but a SubVI iscalled within a VI The relationship between a VI callinga SubVI is similar to a public method in a class callinganother method in a separate class In LabVIEW users candefine their SubVIs and customize an icon for each SubVIThe icon is equivalent to the SubVI in the block diagram

Deeply Nested Subsystem Hierarchy suggests that a VImay contain too many levels of SubVIs For examplemyModelvi includes a myModelSubvi myModelSubviincludes a myModelSubSubvi A model with too manyhierarchies may increase the difficulty in understandingthe model because sub-levels hide the logic and imple-mentation details from top levels This bad smell is alsoidentified and analysed in Simulink model smells (Gerlitzet al 2015)

6 Queries to Detect Smells in Model Reposito-ries

To support querying of LabVIEW models in repositories weextended the Hawk platform to support LabVIEW models anddeveloped a metamodel that captures the properties and rela-tionships across elements in LabVIEW models The followingsubsections discuss how the Hawk framework and LabVIEWmetamodel help to simplify the writing of queries to detectsmells in LabVIEW models

61 HawkHawk is a platform for querying version histories of modelsstored in file-based repositories such as the models that are

2 httpsforumsnicomt5LabVIEWNested-while-loopstd-p2167378profilelanguage=en

3 httpsforumsnicomt5LabVIEWNested-FOR-loops-and-flat-sequence-A-good-designtd-p2454042profilelanguage=en

available in Version Control Systems (VCS) A VCS (eg Git)provides capabilities for tracking changes made to files andhandling conflicts due to file edits by multiple users Howevera traditional VCS does not provide support for managing thecomplex relationships among elements in models that are storedas files thereby leaving such complexities to be handled by theuser (Bartelt 2008)

Hawk provides a common interface for querying modelswhere various parts of the model are stored in different filesThis interface provided by Hawk allows the users to managethe model-specific complexities not handled by a traditionalVCS while still providing full access to the typical VCS ca-pabilities The queries supported by Hawk include detectingchanges across files in a repository adding new model files andextracting models that conform to some metamodel Figure 2provides a graphical overview of Hawk

The Hawk tool adopts a component-based architecture whereeach component can be extended towards a more specific re-quirement The VCS manager component detects and retrieveschanges in files stored in a VCS such as Git while the ModelResource Factory (or model interpreter) translates the files intoa compatible EMF representation The model updater com-pares the models with the latest version that has been storedin a backend database The model updater then performs anincremental update on the backend database to reflect the newlyadded models The query engine provides capabilities to re-trieve information about the models that have been stored inthe backend database The time-aware dialect of Hawk is ableto support time-aware indexing where changes in the modelsare associated with a timestamp that corresponds to when thechanges were made Hawk also provides a time-aware queryengine that can extract historic information about the models

In this paper we extend the time-aware dialect of Hawk tosupport LabVIEW models via a model interpreter and a Lab-VIEW metamodel that captures the properties and relationshipsacross elements in existing LabVIEW models The model inter-preter extracts model elements from LabVIEW model files andconverts the elements to a format supported by Hawk The Hawktool then validates the resulting Hawk-format model against theLabVIEW metamodel thereby ensuring the consistency of themodels processed by Hawk Our adaptation of Hawk allowsefficient querying of LabVIEW models in file-based reposito-ries Figure 3 is a graphical overview of our extended Hawktool The next subsection discusses the LabVIEW metamodelin detail

62 LabVIEW MetamodelTo the best of our knowledge there is no open-source meta-model for LabVIEW nor is there any available specificationdocument that captures the concepts in LabVIEW and the re-lationship among these concepts Hence in our previous workwe developed a LabVIEW metamodel (Popoola amp Gray 2019)via example-driven techniques (such as those used in (Loacutepez-Fernaacutendez et al 2015)) by curating over 100 LabVIEW modelsfrom the LabVIEW examples repository that is present in theLabVIEW IDE The metamodel captures several types of Lab-VIEW dependencies and the relationships that exist across these

6 Popoola et al

Figure 1 A Front Panel and Block Diagram to Add Two Numbers

we do not know of any study that validates this assump-tion Our study aims to discover the prevalence of severalselected bad smells in LabVIEW models stored in openrepositories

RQ2 When are bad smells introduced in LabVIEW modelsFowler (Roberts et al 1999) proposes that bad smells insoftware programs are often introduced due to the evolu-tion and maintenance activities that are performed through-out the programrsquos life cycle This may indicate that badsmells are often introduced at later stages of the softwaredevelopment cycle However Tufano et al (Tufano etal 2015) conducted a study of 5 types of smells in over200 open source Android Apache and Eclipse projectsTheir results show that most smells are present in the firstversion of a program Therefore the results from bothFowler (Roberts et al 1999) and Tufano et al (Tufanoet al 2015) suggest the bad smells may creep into soft-ware at various stages of development We do not knowof a similar study that has been conducted to investigatewhen smells are introduced in LabVIEW models or graph-ical models in general Our study aims to discover thecommon trends of how bad smells are first introduced inLabVIEW repositories

RQ3 What is the relationship between the bad smells and struc-tural changes made to a model This phase of the researchwork aims to unravel the set of changes to a model that ledto the introduction of new smells in the model and the setof changes that led to an increase reduction or removalof bad smells in the model This is a first step to generatea set of best practices for writing programs with minimalsmells as well as the anti-patterns that should be avoideddue to the likelihood of introducing new smells to a model

To answer the research questions mentioned above we imple-mented the following approaches

1 We selected 10 repositories from GitHub These reposito-ries were selected by searching for the keyword labviewnxg in GitHub and the repositories were checked to con-

tain at least one LabVIEW NXG file We were able togather 10 repositories

2 We extended the Hawk tool (see Section 6) to supportquerying the evolution history of LabVIEW models Thismakes it easy to extract the history of LabVIEW models inselected GitHub repositories

3 We constructed seven Hawk queries to detect instances ofseven smells in LabVIEW The execution of the queriesin Hawk will produce the evolution history of smells inselected models

4 We manually analysed the results of the queries to answerthe research questions discussed above

5 Smell SelectionMany smells in LabVIEW have been identified in previousworks Chambers and Scaffidi (Chambers amp Scaffidi 2013) iden-tified smells based on an interview conducted with experiencedLabVIEW developers while Carcao et al (Carccedilao 2014)(Carccedilaoet al 2014) identified more smells based on the rate of energyconsumed when LabVIEW programs are executed Howeverthese smells are more related to performance issues and do notcover a wider range of developerrsquos experience (eg a new de-veloper may find some tasks challenging and it may be trivialto an expert) Due to the number of smells that can be detectedit is practically infeasible for us to analyse all possible smellsthat can be detected in LabVIEW models In this paper weanalysed selected smells that have been extracted from posts inLabVIEW discussion forums (Zhao amp Gray 2019) Due to theopen-nature of these online forums various issues are discussedby developers with a wide-range of expertise hence we believethat the smells captured in this way are representative both interms of the needs of LabVIEW developers and the categoryof programs involved Moreover statistical results show thatend-users are deeply interested in reviewing and replying toposts related to LabVIEW model smells From 2000 to 2019the average review and reply per post are 119739 and 594respectively while the average review and reply related to badsmell posts are 135602 and 1555 respectively

4 Popoola et al

Zhao and Gray (Zhao amp Gray 2019) identified 15 bad smellswhile Chambers and Scaffidi (Chambers amp Scaffidi 2013) iden-tified 13 smells Six of these smells were reported in bothpapers thereby resulting in a net total of 22 smells We se-lected seven of the smells for this study due to the limited costand time required to effectively analyse all of the 22 smellsThe seven smells studied in this paper are 1) Large Variables2) No Wait in a Loop 3) Build Array in a Loop 4) ExcessiveProperty Nodes 5) String Concatenation in Loop 6) Multi-ple Nested Loops and 7) Deeply Nested Subsystem HierarchyThese smells are selected for the following reasons

1 Ease of validation The selected smells have well-definedcriteria for affirming the presence of the specific smell inthe set of models For example the smell No Wait in a Loopmeans that the absence of a Wait element in any loop isconsidered a smell Hence we only need to check whetherany of the loops in a set of models does not contain theWait element in order to affirm the presence of the smell inthe models

2 Scope of inclusion The selected smells cover two majorperspectives of a VI performance and structure Perfor-mance relates to the model execution such as the time amodel needs to run and the memory a program consumeswhile executing No Wait in a Loop is likely to causesynchronization issues (Chambers amp Scaffidi 2013) whilethe Build Array in a Loop smell and the String Concate-nation in a Loop smell slows the programrsquos performanceand causes memory issues (Chambers amp Scaffidi 2013)Multiple Nested Loops occurs when loop structures areembedded in another loop structure This increases themodelrsquos structural complexity reduces readability andmay also lead to other control and performance issuesLarge Variables refers to the use of many variables in amodel Excessive Property Nodes refers to the usage ofProperty Nodes element in a model and Deeply NestedSubsystem Hierarchy refers to when a VI contains toomany levels of subVIs These three smells increase thestructural complexity of a model thus affecting the modelunderstandability

3 Level of granularity The selected smells represent dif-ferent levels of granularity within a VI Large Variablesexamines the usage of the most basic data unit that a VIuses Four smells No Wait in a Loop Build Array in aLoop Excessive Property Nodes and String Concatena-tion in Loop focus on the investigation of smells relatedto a single nodestructure in a systems model MultipleNested Loops explores multiple nodesstructures withina VI that may affect system models and Deeply NestedSubsystem Hierarchy analyses bad smells from a structuralaspect The inspection of these smells at different gran-ularity levels helps us to better understand bad smells insystems models and observe how different smells evolveover time

The following paragraphs provide a detailed description ofeach of the seven smells in our study

A Large Variables

Large Variables refers to the adoption of too many localvariables in a model In LabVIEW a local variable is usedto communicate between structures within one moduleIt is similar to formal parameters of a method in OOPOverusing local variables such as using them to avoidlong wires across a block diagram or using them insteadof data flow can lead to several maintenance issues Localvariables make copies of data buffers If users adopt toomany local variables to transfer large amounts of data fromone place on the block diagram to another more memoryis consumed and may result in slower execution

B No Wait in a Loop

This bad smell often occurs during a data acquisition pro-gram In a general object-oriented program when a ForLoop or a While Loop finishes executing one iteration itmay immediately begin running the next The frequencyof one iteration is usually not considered In LabVIEWmodeling however it is often beneficial to control howoften a loop executes For example in industrial practiceit is important to mark the data acquisition rate If userswant to acquire data in a loop they would need a methodto control the frequency of the data acquisition In thissituation a pause in a loop is necessary Timing a loop alsoallows the processor time to complete other tasks such asupdating and responding to the user interface

C Build Array in a Loop

This bad smell refers to the construction of an array insidea loop structure When an array node is inside a loop everytime the loop starts a new iteration a new copy of the arrayis constructed This process leads to increased memoryconsumption and may cause severe performance issues

D Excessive Property Nodes

The purpose of Property Nodes in a LabVIEW model isto programmatically control the properties of a front-endor user interface object such as color visibility positionnumeric and display format For example users couldchange the color of a dial to go through blue green and redas its numerical value increases However the excessiveusage of Property Nodes can introduce several issues inLabVIEW models One of the issues is that there is a lot ofoverhead with Property Nodes Each Property Node accesswill result in a context switch to the UI thread which willslow model execution

E String Concatenation in a Loop

This bad smell as the name suggests refers to the adoptionof String Concatenation structure inside the body of aloop Chambers and Scaffidi (Chambers amp Scaffidi 2013)first identified this bad smell from their interview withLabVIEW experts They affirm that the implementationof String Concatenation structure in the body of a loopcauses slow performance and memory issues

Evolution of Bad Smells in LabVIEW Graphical Models 5

F Multiple Nested LoopsThis bad smell refers to placing loop structures inside thebody of another loop structure Multiple Nested Loops areconsidered as a negative programming practice because itrsquosexecution is time consuming and it also increases the pro-gramrsquos complexity Many works have been conductedto solve deeply nested problems (Quillereacute et al 2000)(Karunaratne et al 2018) Similar to other programminglanguages the use of nested loops in LabVIEW modelsreduces readability (Chambers amp Scaffidi 2013) and some-times can be problematic when introducing other structuresin the outer loop Due to the nature that LabVIEW is adataflow-driven programming paradigm the introductionof other structures inside of a loop may contribute to con-trol and design issues Many discussions related to theseissues are found in the LabVIEW discussion forum (suchas nested loop control2 design issue3)

G Deeply Nested Subsystem HierarchyModularity is essential for software systems and is sup-ported by decoupling software into reusable units (Exman2014) In LabVIEW modularity is achieved by the adop-tion of a SubVI A SubVI is the same as a VI and it alsocontains a front panel and a block diagram but a SubVI iscalled within a VI The relationship between a VI callinga SubVI is similar to a public method in a class callinganother method in a separate class In LabVIEW users candefine their SubVIs and customize an icon for each SubVIThe icon is equivalent to the SubVI in the block diagram

Deeply Nested Subsystem Hierarchy suggests that a VImay contain too many levels of SubVIs For examplemyModelvi includes a myModelSubvi myModelSubviincludes a myModelSubSubvi A model with too manyhierarchies may increase the difficulty in understandingthe model because sub-levels hide the logic and imple-mentation details from top levels This bad smell is alsoidentified and analysed in Simulink model smells (Gerlitzet al 2015)

6 Queries to Detect Smells in Model Reposito-ries

To support querying of LabVIEW models in repositories weextended the Hawk platform to support LabVIEW models anddeveloped a metamodel that captures the properties and rela-tionships across elements in LabVIEW models The followingsubsections discuss how the Hawk framework and LabVIEWmetamodel help to simplify the writing of queries to detectsmells in LabVIEW models

61 HawkHawk is a platform for querying version histories of modelsstored in file-based repositories such as the models that are

2 httpsforumsnicomt5LabVIEWNested-while-loopstd-p2167378profilelanguage=en

3 httpsforumsnicomt5LabVIEWNested-FOR-loops-and-flat-sequence-A-good-designtd-p2454042profilelanguage=en

available in Version Control Systems (VCS) A VCS (eg Git)provides capabilities for tracking changes made to files andhandling conflicts due to file edits by multiple users Howevera traditional VCS does not provide support for managing thecomplex relationships among elements in models that are storedas files thereby leaving such complexities to be handled by theuser (Bartelt 2008)

Hawk provides a common interface for querying modelswhere various parts of the model are stored in different filesThis interface provided by Hawk allows the users to managethe model-specific complexities not handled by a traditionalVCS while still providing full access to the typical VCS ca-pabilities The queries supported by Hawk include detectingchanges across files in a repository adding new model files andextracting models that conform to some metamodel Figure 2provides a graphical overview of Hawk

The Hawk tool adopts a component-based architecture whereeach component can be extended towards a more specific re-quirement The VCS manager component detects and retrieveschanges in files stored in a VCS such as Git while the ModelResource Factory (or model interpreter) translates the files intoa compatible EMF representation The model updater com-pares the models with the latest version that has been storedin a backend database The model updater then performs anincremental update on the backend database to reflect the newlyadded models The query engine provides capabilities to re-trieve information about the models that have been stored inthe backend database The time-aware dialect of Hawk is ableto support time-aware indexing where changes in the modelsare associated with a timestamp that corresponds to when thechanges were made Hawk also provides a time-aware queryengine that can extract historic information about the models

In this paper we extend the time-aware dialect of Hawk tosupport LabVIEW models via a model interpreter and a Lab-VIEW metamodel that captures the properties and relationshipsacross elements in existing LabVIEW models The model inter-preter extracts model elements from LabVIEW model files andconverts the elements to a format supported by Hawk The Hawktool then validates the resulting Hawk-format model against theLabVIEW metamodel thereby ensuring the consistency of themodels processed by Hawk Our adaptation of Hawk allowsefficient querying of LabVIEW models in file-based reposito-ries Figure 3 is a graphical overview of our extended Hawktool The next subsection discusses the LabVIEW metamodelin detail

62 LabVIEW MetamodelTo the best of our knowledge there is no open-source meta-model for LabVIEW nor is there any available specificationdocument that captures the concepts in LabVIEW and the re-lationship among these concepts Hence in our previous workwe developed a LabVIEW metamodel (Popoola amp Gray 2019)via example-driven techniques (such as those used in (Loacutepez-Fernaacutendez et al 2015)) by curating over 100 LabVIEW modelsfrom the LabVIEW examples repository that is present in theLabVIEW IDE The metamodel captures several types of Lab-VIEW dependencies and the relationships that exist across these

6 Popoola et al

Zhao and Gray (Zhao amp Gray 2019) identified 15 bad smellswhile Chambers and Scaffidi (Chambers amp Scaffidi 2013) iden-tified 13 smells Six of these smells were reported in bothpapers thereby resulting in a net total of 22 smells We se-lected seven of the smells for this study due to the limited costand time required to effectively analyse all of the 22 smellsThe seven smells studied in this paper are 1) Large Variables2) No Wait in a Loop 3) Build Array in a Loop 4) ExcessiveProperty Nodes 5) String Concatenation in Loop 6) Multi-ple Nested Loops and 7) Deeply Nested Subsystem HierarchyThese smells are selected for the following reasons

1 Ease of validation The selected smells have well-definedcriteria for affirming the presence of the specific smell inthe set of models For example the smell No Wait in a Loopmeans that the absence of a Wait element in any loop isconsidered a smell Hence we only need to check whetherany of the loops in a set of models does not contain theWait element in order to affirm the presence of the smell inthe models

2 Scope of inclusion The selected smells cover two majorperspectives of a VI performance and structure Perfor-mance relates to the model execution such as the time amodel needs to run and the memory a program consumeswhile executing No Wait in a Loop is likely to causesynchronization issues (Chambers amp Scaffidi 2013) whilethe Build Array in a Loop smell and the String Concate-nation in a Loop smell slows the programrsquos performanceand causes memory issues (Chambers amp Scaffidi 2013)Multiple Nested Loops occurs when loop structures areembedded in another loop structure This increases themodelrsquos structural complexity reduces readability andmay also lead to other control and performance issuesLarge Variables refers to the use of many variables in amodel Excessive Property Nodes refers to the usage ofProperty Nodes element in a model and Deeply NestedSubsystem Hierarchy refers to when a VI contains toomany levels of subVIs These three smells increase thestructural complexity of a model thus affecting the modelunderstandability

3 Level of granularity The selected smells represent dif-ferent levels of granularity within a VI Large Variablesexamines the usage of the most basic data unit that a VIuses Four smells No Wait in a Loop Build Array in aLoop Excessive Property Nodes and String Concatena-tion in Loop focus on the investigation of smells relatedto a single nodestructure in a systems model MultipleNested Loops explores multiple nodesstructures withina VI that may affect system models and Deeply NestedSubsystem Hierarchy analyses bad smells from a structuralaspect The inspection of these smells at different gran-ularity levels helps us to better understand bad smells insystems models and observe how different smells evolveover time

The following paragraphs provide a detailed description ofeach of the seven smells in our study

A Large Variables

Large Variables refers to the adoption of too many localvariables in a model In LabVIEW a local variable is usedto communicate between structures within one moduleIt is similar to formal parameters of a method in OOPOverusing local variables such as using them to avoidlong wires across a block diagram or using them insteadof data flow can lead to several maintenance issues Localvariables make copies of data buffers If users adopt toomany local variables to transfer large amounts of data fromone place on the block diagram to another more memoryis consumed and may result in slower execution

B No Wait in a Loop

This bad smell often occurs during a data acquisition pro-gram In a general object-oriented program when a ForLoop or a While Loop finishes executing one iteration itmay immediately begin running the next The frequencyof one iteration is usually not considered In LabVIEWmodeling however it is often beneficial to control howoften a loop executes For example in industrial practiceit is important to mark the data acquisition rate If userswant to acquire data in a loop they would need a methodto control the frequency of the data acquisition In thissituation a pause in a loop is necessary Timing a loop alsoallows the processor time to complete other tasks such asupdating and responding to the user interface

C Build Array in a Loop

This bad smell refers to the construction of an array insidea loop structure When an array node is inside a loop everytime the loop starts a new iteration a new copy of the arrayis constructed This process leads to increased memoryconsumption and may cause severe performance issues

D Excessive Property Nodes

The purpose of Property Nodes in a LabVIEW model isto programmatically control the properties of a front-endor user interface object such as color visibility positionnumeric and display format For example users couldchange the color of a dial to go through blue green and redas its numerical value increases However the excessiveusage of Property Nodes can introduce several issues inLabVIEW models One of the issues is that there is a lot ofoverhead with Property Nodes Each Property Node accesswill result in a context switch to the UI thread which willslow model execution

E String Concatenation in a Loop

This bad smell as the name suggests refers to the adoptionof String Concatenation structure inside the body of aloop Chambers and Scaffidi (Chambers amp Scaffidi 2013)first identified this bad smell from their interview withLabVIEW experts They affirm that the implementationof String Concatenation structure in the body of a loopcauses slow performance and memory issues

Evolution of Bad Smells in LabVIEW Graphical Models 5

F Multiple Nested LoopsThis bad smell refers to placing loop structures inside thebody of another loop structure Multiple Nested Loops areconsidered as a negative programming practice because itrsquosexecution is time consuming and it also increases the pro-gramrsquos complexity Many works have been conductedto solve deeply nested problems (Quillereacute et al 2000)(Karunaratne et al 2018) Similar to other programminglanguages the use of nested loops in LabVIEW modelsreduces readability (Chambers amp Scaffidi 2013) and some-times can be problematic when introducing other structuresin the outer loop Due to the nature that LabVIEW is adataflow-driven programming paradigm the introductionof other structures inside of a loop may contribute to con-trol and design issues Many discussions related to theseissues are found in the LabVIEW discussion forum (suchas nested loop control2 design issue3)

G Deeply Nested Subsystem HierarchyModularity is essential for software systems and is sup-ported by decoupling software into reusable units (Exman2014) In LabVIEW modularity is achieved by the adop-tion of a SubVI A SubVI is the same as a VI and it alsocontains a front panel and a block diagram but a SubVI iscalled within a VI The relationship between a VI callinga SubVI is similar to a public method in a class callinganother method in a separate class In LabVIEW users candefine their SubVIs and customize an icon for each SubVIThe icon is equivalent to the SubVI in the block diagram

Deeply Nested Subsystem Hierarchy suggests that a VImay contain too many levels of SubVIs For examplemyModelvi includes a myModelSubvi myModelSubviincludes a myModelSubSubvi A model with too manyhierarchies may increase the difficulty in understandingthe model because sub-levels hide the logic and imple-mentation details from top levels This bad smell is alsoidentified and analysed in Simulink model smells (Gerlitzet al 2015)

6 Queries to Detect Smells in Model Reposito-ries

To support querying of LabVIEW models in repositories weextended the Hawk platform to support LabVIEW models anddeveloped a metamodel that captures the properties and rela-tionships across elements in LabVIEW models The followingsubsections discuss how the Hawk framework and LabVIEWmetamodel help to simplify the writing of queries to detectsmells in LabVIEW models

61 HawkHawk is a platform for querying version histories of modelsstored in file-based repositories such as the models that are

2 httpsforumsnicomt5LabVIEWNested-while-loopstd-p2167378profilelanguage=en

3 httpsforumsnicomt5LabVIEWNested-FOR-loops-and-flat-sequence-A-good-designtd-p2454042profilelanguage=en

available in Version Control Systems (VCS) A VCS (eg Git)provides capabilities for tracking changes made to files andhandling conflicts due to file edits by multiple users Howevera traditional VCS does not provide support for managing thecomplex relationships among elements in models that are storedas files thereby leaving such complexities to be handled by theuser (Bartelt 2008)

Hawk provides a common interface for querying modelswhere various parts of the model are stored in different filesThis interface provided by Hawk allows the users to managethe model-specific complexities not handled by a traditionalVCS while still providing full access to the typical VCS ca-pabilities The queries supported by Hawk include detectingchanges across files in a repository adding new model files andextracting models that conform to some metamodel Figure 2provides a graphical overview of Hawk

The Hawk tool adopts a component-based architecture whereeach component can be extended towards a more specific re-quirement The VCS manager component detects and retrieveschanges in files stored in a VCS such as Git while the ModelResource Factory (or model interpreter) translates the files intoa compatible EMF representation The model updater com-pares the models with the latest version that has been storedin a backend database The model updater then performs anincremental update on the backend database to reflect the newlyadded models The query engine provides capabilities to re-trieve information about the models that have been stored inthe backend database The time-aware dialect of Hawk is ableto support time-aware indexing where changes in the modelsare associated with a timestamp that corresponds to when thechanges were made Hawk also provides a time-aware queryengine that can extract historic information about the models

In this paper we extend the time-aware dialect of Hawk tosupport LabVIEW models via a model interpreter and a Lab-VIEW metamodel that captures the properties and relationshipsacross elements in existing LabVIEW models The model inter-preter extracts model elements from LabVIEW model files andconverts the elements to a format supported by Hawk The Hawktool then validates the resulting Hawk-format model against theLabVIEW metamodel thereby ensuring the consistency of themodels processed by Hawk Our adaptation of Hawk allowsefficient querying of LabVIEW models in file-based reposito-ries Figure 3 is a graphical overview of our extended Hawktool The next subsection discusses the LabVIEW metamodelin detail

62 LabVIEW MetamodelTo the best of our knowledge there is no open-source meta-model for LabVIEW nor is there any available specificationdocument that captures the concepts in LabVIEW and the re-lationship among these concepts Hence in our previous workwe developed a LabVIEW metamodel (Popoola amp Gray 2019)via example-driven techniques (such as those used in (Loacutepez-Fernaacutendez et al 2015)) by curating over 100 LabVIEW modelsfrom the LabVIEW examples repository that is present in theLabVIEW IDE The metamodel captures several types of Lab-VIEW dependencies and the relationships that exist across these

6 Popoola et al

F Multiple Nested LoopsThis bad smell refers to placing loop structures inside thebody of another loop structure Multiple Nested Loops areconsidered as a negative programming practice because itrsquosexecution is time consuming and it also increases the pro-gramrsquos complexity Many works have been conductedto solve deeply nested problems (Quillereacute et al 2000)(Karunaratne et al 2018) Similar to other programminglanguages the use of nested loops in LabVIEW modelsreduces readability (Chambers amp Scaffidi 2013) and some-times can be problematic when introducing other structuresin the outer loop Due to the nature that LabVIEW is adataflow-driven programming paradigm the introductionof other structures inside of a loop may contribute to con-trol and design issues Many discussions related to theseissues are found in the LabVIEW discussion forum (suchas nested loop control2 design issue3)

G Deeply Nested Subsystem HierarchyModularity is essential for software systems and is sup-ported by decoupling software into reusable units (Exman2014) In LabVIEW modularity is achieved by the adop-tion of a SubVI A SubVI is the same as a VI and it alsocontains a front panel and a block diagram but a SubVI iscalled within a VI The relationship between a VI callinga SubVI is similar to a public method in a class callinganother method in a separate class In LabVIEW users candefine their SubVIs and customize an icon for each SubVIThe icon is equivalent to the SubVI in the block diagram

Deeply Nested Subsystem Hierarchy suggests that a VImay contain too many levels of SubVIs For examplemyModelvi includes a myModelSubvi myModelSubviincludes a myModelSubSubvi A model with too manyhierarchies may increase the difficulty in understandingthe model because sub-levels hide the logic and imple-mentation details from top levels This bad smell is alsoidentified and analysed in Simulink model smells (Gerlitzet al 2015)

6 Queries to Detect Smells in Model Reposito-ries

To support querying of LabVIEW models in repositories weextended the Hawk platform to support LabVIEW models anddeveloped a metamodel that captures the properties and rela-tionships across elements in LabVIEW models The followingsubsections discuss how the Hawk framework and LabVIEWmetamodel help to simplify the writing of queries to detectsmells in LabVIEW models

61 HawkHawk is a platform for querying version histories of modelsstored in file-based repositories such as the models that are

2 httpsforumsnicomt5LabVIEWNested-while-loopstd-p2167378profilelanguage=en

3 httpsforumsnicomt5LabVIEWNested-FOR-loops-and-flat-sequence-A-good-designtd-p2454042profilelanguage=en

available in Version Control Systems (VCS) A VCS (eg Git)provides capabilities for tracking changes made to files andhandling conflicts due to file edits by multiple users Howevera traditional VCS does not provide support for managing thecomplex relationships among elements in models that are storedas files thereby leaving such complexities to be handled by theuser (Bartelt 2008)

Hawk provides a common interface for querying modelswhere various parts of the model are stored in different filesThis interface provided by Hawk allows the users to managethe model-specific complexities not handled by a traditionalVCS while still providing full access to the typical VCS ca-pabilities The queries supported by Hawk include detectingchanges across files in a repository adding new model files andextracting models that conform to some metamodel Figure 2provides a graphical overview of Hawk

The Hawk tool adopts a component-based architecture whereeach component can be extended towards a more specific re-quirement The VCS manager component detects and retrieveschanges in files stored in a VCS such as Git while the ModelResource Factory (or model interpreter) translates the files intoa compatible EMF representation The model updater com-pares the models with the latest version that has been storedin a backend database The model updater then performs anincremental update on the backend database to reflect the newlyadded models The query engine provides capabilities to re-trieve information about the models that have been stored inthe backend database The time-aware dialect of Hawk is ableto support time-aware indexing where changes in the modelsare associated with a timestamp that corresponds to when thechanges were made Hawk also provides a time-aware queryengine that can extract historic information about the models

In this paper we extend the time-aware dialect of Hawk tosupport LabVIEW models via a model interpreter and a Lab-VIEW metamodel that captures the properties and relationshipsacross elements in existing LabVIEW models The model inter-preter extracts model elements from LabVIEW model files andconverts the elements to a format supported by Hawk The Hawktool then validates the resulting Hawk-format model against theLabVIEW metamodel thereby ensuring the consistency of themodels processed by Hawk Our adaptation of Hawk allowsefficient querying of LabVIEW models in file-based reposito-ries Figure 3 is a graphical overview of our extended Hawktool The next subsection discusses the LabVIEW metamodelin detail

62 LabVIEW MetamodelTo the best of our knowledge there is no open-source meta-model for LabVIEW nor is there any available specificationdocument that captures the concepts in LabVIEW and the re-lationship among these concepts Hence in our previous workwe developed a LabVIEW metamodel (Popoola amp Gray 2019)via example-driven techniques (such as those used in (Loacutepez-Fernaacutendez et al 2015)) by curating over 100 LabVIEW modelsfrom the LabVIEW examples repository that is present in theLabVIEW IDE The metamodel captures several types of Lab-VIEW dependencies and the relationships that exist across these

6 Popoola et al

Figure 2 The Hawk Tool (Barmpis et al 2020)

Figure 3 The Extended Hawk Tool

Evolution of Bad Smells in LabVIEW Graphical Models 7

dependencies Figure 4 shows a simplified view of the meta-model

We simplify the amount of effort required to translate a badsmell into an efficient query method via an extensible and care-fully designed metamodel that captures the relationships amongthe elements in a LabVIEW model The metamodel supportsOOP concepts such as inheritance thereby making it possible togroup related elements The selected bad smells focus on struc-tures and certain characteristics that have been known to suggesta bad design The constructed metamodel captures these struc-tures and characteristics thereby simplifying the query neededto identify these properties in a LabVIEW model The query toidentify smells has to be manually constructed but the detectionand historical evolution of smells based on the queries has beenautomated A sample query was developed for each of the badsmells (from Section 5) to detect the presence of the bad smellsin the repositories It should be noted that the metamodel canbe used to simplify the query for detecting any arbitrary badsmells that focus on the structural properties of a LabVIEWmodel Furthermore because the LabVIEW metamodel wasdeveloped by curating sample models it is possible that themetamodel may not cover all possible features in a LabVIEWmodel However the metamodel is open-source and extensibletherefore it can be easily extended by anyone to accommodatemore features that are not currently covered

For Large Variables we extracted the total number of vari-ables in each model The No Wait in a Loop bad smell wasextracted by examining all of the loops (Both While Loop andFor Loop) and recursively checking for the presence of a Waitelement in any of the loops The Build Array in a Loop and theString Concatenation in Loop bad smells were identified in asimilar way to the No Wait in a Loop smell except that the BuildArray and String Concatenation elements were respectively theobject of interest in the loops The Excessive Property Nodesbad smell was extracted via the Property Node type defined inthe metamodel Multiple Nested Loops was extracted by search-ing for all the loop structures that have another loop structureembedded within them Finally instances of the Deeply NestedSubsystem Hierarchy smell was detected by first extracting allthe subVIrsquos in a Model and then searching through the extractedsubVIs for any one that has at least one subVI In LabVIEW asubVI is usually a complete VI in another file that is called byits parent VI

The correctness of the queries has been manually verifiedby randomly selecting four models that return a positive resultfor a smell and four models where the execution of a query didnot detect instances of the smell This process was repeatedfor all of the seven queries The only exception was the BuildArray in the Loop smell where the execution of the query de-tected instances of the smell in only two models Thereforeonly two models were used to verify the positive result Theresults of the verification process shows that the queries were100 correct The complete open-source LabVIEW metamodelmodel interpreter and all of the seven queries developed to ex-tract the bad smells are publicly available online (please seehttpbitlyLMeta)

Repo Properties

URL for Repository ofModels

ofElements

Repo 1 httpsgithubcomniwebvi-examples

1 680

Repo 2 httpsgithubcomJKISoftwareJKI-State-Machine-NXG

10 5537

Repo 3 httpsgithubcomnilabview-nxg-jenkins-build

14 270

Repo 4 httpsgithubcomrajsite webvi-hack

11 654

Repo 5 httpsgithubcomprestwickcustomizing-webvis

5 1650

Repo 6 httpsgithubcomtherinoyLabVIEW-NXG-BL11W-Web-App-Project

3 1312

Repo 7 httpsgithubcomnavinsubrama-nidevelop-and-deploy-WebVI

15 487

Repo 8 httpsgithubcomwimtormansLabVIEWRaspber-ryPI_IndoorMonitoring

8 1947

Repo 9 httpsgithubcomeyesonvisniweek2019-webVI-hands-on

3 538

Repo 10 httpsgithubcomdoczhivagoDownloadUploadAFileWebVI

6 171

Table 1 Overview of 10 Repositories and Identified Smells

7 Research Questions and AnalysisWe developed three research questions to study the evolutionof LabVIEW models The research questions deal with theintroduction and prevalence of bad smells in LabVIEW reposi-tories as well as the structural changes to models that are likelyto introduce bad smells The research questions which werediscussed in more detail in Section 4 are as follows

RQ1 How prevalent are bad smells in a LabVIEW model

RQ2 When are bad smells introduced in a LabVIEW model

RQ3 What is the relationship between the bad smells and struc-tural changes made to the models

To answer these research questions a preliminary investigationand analysis of the selected seven bad smells was performedon 81 LabVIEW models stored in 10 GitHub repositories ofvarying size and complexity An initial set of selected projectswere identified and the models embedded in these projects werevalidated against our LabVIEW metamodel The metamodelwas also updated to accommodate new relationships that wereobserved across the 10 public projects containing 81 LabVIEWmodels Table 1 gives an overview of the repositories Thefollowing subsections address each of the research questions

8 Popoola et al

Figure 4 A simplified LabVIEW metamodel (Popoola amp Gray 2019)

and provides an in-depth study of the evolution of bad smells inLabVIEW models

71 Prevalence of Bad Smells in LabVIEW Models

To answer the question related to the prevalence of bad smellsin LabVIEW models we queried the repository to check for thepresence of each of the seven selected bad smells in the iden-tified repositories Table 2 shows that most of the repositoriescontain instances of 2 or 3 kinds of smells across the life cycleof the models embedded in the repositories Furthermore thesize and complexity of the models embedded in the repositoriesdoes not seem to affect the possibility of the models containinga bad smell This may also validate the hypothesis that thedevelopers are not very familiar with software engineering de-sign principles because bad smells are often associated with badsoftware engineering practices (Van Emden amp Moonen 2002)Table 2 gives a breakdown of the presence of each of the badsmells in the life cycle of the models stored in the repositories

72 When are Bad Smells Introduced

The introduction and consequent increasedecrease of instancesof a bad smell is very important to understand the impact ofmaintenance activities in the life cycle of LabVIEW modelsTo answer this research question we first checked for wheninstances of each smell was first detected in each repositoryThe results show that 55 of the smells were introduced inthe first version of the repositories 17 of the smells wereintroduced in the second version and the remaining 27 wereintroduced in other versions This result shows that bad smellsare introduced at various stages of the software developmentprocess but most of the smells were introduced at the initialversion This suggests that software maintenance activities arenot solely responsible for the introduction of bad smells Figure5 summarizes the results corresponding to when a bad smell isintroduced

The number of bad smell instances also tends to increasesteadily over time and then decline after a peak period Figures6 7 8 9 shows the evolution of four types of smells across theversion history of the repositories It should be noted that thesmells String Concatenation in Loop Deeply Nested Subsys-tem Hierarchy and Build Array in a Loop have been omittedfrom the figures This is because only trivial changes wereobserved in the number of smell instances across the versionhistory of models in all the repositories Furthermore some ofthe repositories have less than 7 versions hence there may bea constant value from the last version number to the ldquocurrentversionrdquo specified in the figures We also analysed the evolutionof all the smells in each repository as the size of the modelsincreased While the full data is provided in the GitHub reposi-tory we provide a sample analysis of repository 2 Figure 10gives an overview of the evolution of smells in repository 2while Figure 11 shows the increasing size of the models in therepository within the same period However it should be notedthat while the overall size of the models increased throughoutthe life cycle of repository 2 the number of model elementsactually decreased in versions after the peak period

73 Structural Changes Related to Bad SmellsThe evolution of a model necessitates the continuous introduc-tion of new changes to the model These changes are neededfor various reasons such as adapting the model to new require-ments fixing a bug or making the model easier to understandHowever these changes may introduce new unintended smellswithin the model This phase of the research identifies the setof structural changes that led to the introduction increase orreduction of bad smells in the models

We used EMFCompare (Toulmeacute amp Inc 2006) to extract thestructural differences between different versions of LabVIEWModels EMFCompare is a model differencing framework forextracting differences between two or three sets of models Two-way differencing involves the direct comparison of two models

Evolution of Bad Smells in LabVIEW Graphical Models 9

Repo Smells LargeVariables

No Wait Build Array PropertyNode

String Con-catenation

Nested Loop Nested Sub-system

Repo 1 yes yes no no no yes yes

Repo 2 yes yes no yes no yes yes

Repo 3 no no no yes no no no

Repo 4 yes yes no yes no no no

Repo 5 yes yes no yes no yes no

Repo 6 no yes yes no yes no no

Repo 7 yes yes no yes no yes no

Repo 8 yes yes no yes no no no

Repo 9 yes yes no no no no no

Repo 10 yes yes no yes no no no

Table 2 Detection of Each Smell across 10 Repositories

Figure 5 Smell Introduction across Repositories

10 Popoola et al

Figure 6 Evolution of Multiple Nested Loops Across VersionHistory of LabVIEW Models

Figure 7 Evolution of No Wait in a Loop Across VersionHistory of LabVIEW Models

Figure 8 Evolution of Excessive Property Nodes AcrossVersion History of LabVIEW Models

Figure 9 Evolution of Large Variables Across Version Historyof LabVIEW Models

Figure 10 Evolution of Bad Smells in Repository 2

Figure 11 Evolution of the Model Size in Repository 2

Evolution of Bad Smells in LabVIEW Graphical Models 11

RepoDiffKind

AvgADD

AvgDELETE

AvgCHANGE

AvgMOVE

Repo 1 322 0 0 0

Repo 2 998 0 0 0

Repo 3 270 0 0 0

Repo 4 2288 15 122 106

Repo 5 4532 521 824 79

Repo 6 658 1 5 0

Repo 7 487 0 0 0

Repo 8 894 25 105 15

Repo 9 538 0 0 0

Repo 10 159 0 0 0

Table 3 Average Number of Difference Types Across VersionHistory

while three-way differencing involves the comparison of twomodels based on their evolution via a third common modelFor this study we used the two-way differencing for directcomparison between models in a specific version and models inthe succeeding version EMFCompare supports four types ofchanges between two sets of models ADD to indicate additionof new elements DELETE to show removal of existing elementsCHANGE to indicate the change of attribute values and MOVEto indicate reordering of elements

To analyse the differences in models across various versionseach version of the models in the identified repository was ex-tracted converted to an XMI format and then compared with itssucceeding version using EMFCompare for efficient extractionof changes between the versions These sets of changes werethen aggregated and analysed for all versions in a repositoryThis analysis makes it easy to understand the changes that ne-cessitate the evolution of LabVIEW programs These structuralchanges to the models were then mapped to the changes in thebad smells exhibited by such models

The results of the analysis of changes across the versionhistory of LabVIEW models in the 10 repositories show thatthe majority of the changes involved addition of new elementsTable 3 shows the average number of modifications that areperformed across each version in the repositories

The addition of new elements to succeeding versions alsocorresponds to increasing instances of smells in the repositoryFurthermore versions with a lower number of smell instancesare also associated with a higher number of deletions and at-tribute changes than number of additions Figure 12 shows thetrend of different kinds of changes in repository 2 It should benoted that there was a sharp increase in the number of deletionsand re-orderings (move) of elements There was also a decrease

Figure 12 Evolution of Change Kinds in Repository 2

in the number of additions This corresponds to the decrease inbad smells shown in Figures 6 to 9

8 Threats to ValidityThis paper presents an analysis of bad smells in LabVIEW mod-els Although a number of steps have been taken to ensure thatthe results presented in this paper are valid and generalizablewe have identified at least four main threats to the validity ofthe results presented in this paper

A Small sample size The sample size of the models used inthis evaluation is rather small and thus the results may notbe generalizable to all LabVIEW models The small sam-ple size is due to the relative young age of the LabVIEWNXG platform and the limited number of open-sourcerepositories that contain LAbVIEW NXG models

B Author demographics We do not know the experienceof the engineers who published the selected projects andhow their experience affected the quality of the selectedmodels It is possible that more experienced developersare able to produce models with higher quality and fewerinstances of bad smells Unfortunately information aboutthe author demographics could not be extracted from theGitHub repositories used in this study

C LabVIEW-specific smells and models The paper only con-siders LabVIEW models for the evaluation and some ofthe smells are specific to the LabVIEW environment Fur-thermore even though some of the smells are applicable toother systems modelling or data acquisition platforms thispaper only considers the effect of the smells on LabVIEWmodels Hence the results may not be generalizable for allsystems modeling or data acquisition environments

D Correctness of the queries The results presented in thispaper depend on the correctness of the queries used toidentify instances of bad smells in the LabVIEW modelsAlthough we have ensured that the queries in this paperare correct it may be possible that a new query generatessome false negatives or false positives

12 Popoola et al

We plan to address each of these concerns as part of futurework However we believe that the results reported in thispaper provide significant insight into the general evolution ofbad smells in systems models

9 Related WorkMuch work exists on bad smell identification in text-based lan-guages Chatzigeorgiou et al (Chatzigeorgiou amp Manakos2014) investigated the presence and persistence of bad smellsin two open source projects Their results show that bad smellsare introduced at the initial version and often persist up to thecurrent version of a project Furthermore the few eliminatedsmells often occur from a side effect of routine maintenanceactivities instead of a refactoring activity that specifically targetsthe removal of the smell Olbrich et al (Olbrich et al 2009)also conducted a similar study and concluded that code withsmells are more prone to frequent changes than projects that donot contain bad smells Tahmid et al (Tahmid et al 2016) alsopresented an approach for analysing bad smells in code reposi-tories based on the relationships between different bad smellsand the architecture of the source code The approach simplifiesthe development of clusters of bad smells embedded in the codefor easy refactoring However all of these approaches focuson text-based languages and none of them considered systemsmodels developed via graphical languages

Some work has been done to identify bad smells in graphicallanguages Simulink provides an interactive graphical envi-ronment for modeling simulating and analysing of dynamicsystems It includes a comprehensive library of predefinedblocks to be used to construct graphical models of systems us-ing drag-and-drop mouse operations Bad smells in Simulinksystems models are identified by Gerlitz et al (Gerlitz et al2015) In this work the authors summarized 21 bad smellsinto 5 categories name partition interface signal flow andsignal structure Two tools Artshopr (Thomas et al 2016) andSLRefactor (Tran amp Dziobek 2013) were implemented to ad-dress these bad smells Stephan and Cordy adopted near-misscross-clone detection to find instances of antipatterns derivedfrom the literature in public Simulink projects (Stephan amp Cordy2015)

Chambers and Scaffidi (Chambers amp Scaffidi 2013) devel-oped an approach for identifying bad smells in systems modelsvia interviews with modeling experts In our own earlier workwe developed an approach for identifying bad smells in Lab-VIEW models from an end-usersrsquo perspective by mining onlineforum posts (Zhao amp Gray 2019) However both (Chambersamp Scaffidi 2013) and (Zhao amp Gray 2019) do not investigatethe presence of the identified smells in code repositories nor dothey study the evolution of such smells This paper extends theliterature by proposing techniques for identifying bad smells ingraphical languages and analysing the evolution of such smellsacross the version history of the software systems developed

10 Conclusion and Future WorkWe introduced a semi-automated approach for detecting andanalysing bad smells in LabVIEW models via user-defined

queries The support for inheritance relationships in the Lab-VIEW metamodel was exploited to simplify the development ofuser queries to detect known bad smells from systems modelsThe approach has been evaluated on 69 models in 10 GitHubrepositories The evaluation process includes the analysis offour selected bad smells reported by end users The prelimi-nary results suggest that most smells are introduced in the earlyversions of a model and these smells often persist throughoutthe life cycle of the modeled system Furthermore most of theprojects contain three or four types of smells This may be anindication of the need for more automated analysis and refactor-ing support for systems engineers who may not be familiar withbad smell identification and refactoring

In the future we plan to carry out an extensive analysis onmore GitHub projects and other graphical modeling tools suchas Simulink The majority of the smells discussed in this paperare specific to LabVIEW hence we plan to cover more smellssuch as ldquoDuplicate Modelrdquo that can be generalizable to othergraphical modelling environments We also plan to conductqualitative studies that will complement the results presented inthis paper We will conduct studies to understand the contextin which bad smells are introduced the relationship betweenauthor demographics and bad smells and the level of consid-eration given to bad smells by LabVIEW developers Further-more we will implement and study the benefits of a refactoringmechanism to address the challenges of bad smells from theperspective of a systems engineer Finally we plan to improveour study to identify refactoring activities that specifically targetthe reduction of bad smells discover the impacts of bad smellson maintenance activities and highlight the differences in theanalysis of bad smells in graphical and textual languages

Acknowledgements

The authors would like to appreciate the contribution of DrTaylor Richeacute (National Instruments) and Dr Antonio Garcia-Dominguez (Aston University UK) for their help with generalquestions for LabVIEW and Hawk respectively We wouldalso like to thank the editors and reviewers for their time andinsightful feedback

References

Barmpis K Garciacutea-Domiacutenguez A Bagnato A amp AbherveA (2020) Monitoring model analytics over large repositorieswith hawk and measure In Model Management and Analyticsfor Large Scale Systems (pp 87ndash123) Elsevier

Barmpis K amp Kolovos D S (2014) Towards scalablequerying of large-scale models In 10th European Conferenceon Modelling Foundations and Applications (pp 35ndash50)

Bartelt C (2008) Consistence preserving model merge incollaborative development processes In Proceedings of theInternational Workshop on Comparison and Versioning ofSoftware Models (pp 13ndash18)

Carccedilao T (2014) Measuring and visualizing energy consump-tion within software code In IEEE Symposium on VisualLanguages and Human-Centric Computing (pp 181ndash182)

Evolution of Bad Smells in LabVIEW Graphical Models 13

Carccedilao T Cunha J Fernandes J P Pereira R amp Saraiva J(2014) Energy consumption detection in LabVIEW In IEEESymposium on Visual Languages and Human-Centric Com-puting Travel Support Competition httpwww4diuminhopt~jasResearchPapersnationalInstrumentspdf

Chambers C amp Scaffidi C (2013) Smell-driven performanceanalysis for end-user programmers In IEEE Symposiumon Visual Languages and Human Centric Computing (pp159ndash166)

Chatzigeorgiou A amp Manakos A (2014) Investigating theevolution of code smells in object-oriented systems Innova-tions in Systems and Software Engineering 10(1) 3ndash18

Exman I (2014) Linear software models standard modu-larity highlights residual coupling International Journal ofSoftware Engineering and Knowledge Engineering 24(02)183ndash210

Falcon J (2017) Facilitating modeling and simulation of com-plex systems through interoperable software In Keynote ad-dress at 20th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems

Gamma E Helm R Johnson R amp Vlissides J (1995) De-sign patterns Elements of reusable object-oriented softwareUSA Addison-Wesley Longman Publishing Co Inc

Garciacutea-Domiacutenguez A Bencomo N Parra-Ullauri J M ampGarciacutea-Paucar L H (2019) Querying and annotating modelhistories with time-aware patterns In 22nd ACMIEEE In-ternational Conference on Model Driven Engineering Lan-guages and Systems (pp 194ndash204)

Gerlitz T Tran Q M amp Dziobek C (2015) Detection andhandling of model smells for MATLABSimulink modelsIn Modeling in Automotive Software Engineering Workshopat the 18th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems (pp 13ndash22)

Johnson G W (1997) LabVIEW Graphical ProgrammingTata McGraw-Hill Education

Karunaratne M Tan C Kulkarni A Mitra T amp Peh L-S(2018) Dnestmap mapping deeply-nested loops on ultra-low power cgras In Proceedings of the 55th Annual DesignAutomation Conference (pp 1ndash6)

Loacutepez-Fernaacutendez J J Cuadrado J S Guerra E amp De Lara J(2015) Example-driven meta-model development Softwareand Systems Modeling 14(4) 1323ndash1347

Ludewig J (2003) Models in software engineeringndashAn intro-duction Software and Systems Modeling 2(1) 5ndash14

Olbrich S Cruzes D S Basili V amp Zazworka N (2009)The evolution and impact of code smells A case study oftwo open source systems In 3rd International Symposiumon Empirical Software Engineering and Measurement (pp390ndash400)

Opdyke W F (1992) Refactoring object-oriented frameworks(Unpublished doctoral dissertation) University of Illinois atUrbana-Champaign Champaign IL USA

Popoola S amp Gray J (2019) A LabVIEW metamodel forautomated analysis In International Conference on Com-putational Science and Computational Intelligence (p 1127-1132)

Quillereacute F Rajopadhye S amp Wilde D (2000) Generation of

efficient nested loops from polyhedra International Journalof Parallel Programming 28(5) 469ndash498

Robbes R Kamei Y amp Pinzger M (2017) Guest EditorialMining software repositories Empirical Software Engineer-ing 22(3) 1143ndash1145

Roberts D Opdyke W Beck K Fowler M amp Brant J(1999) Refactoring Improving the Design of Existing CodeAddison-Wesley Longman Publishing Boston

Services E (nd) Companies using labview httpsenlyftcomtechproductslabview (Accessed January 2020)

Stephan M amp Cordy J R (2015) Identification of Simulinkmodel antipattern instances using model clone detection In18th ACMIEEE International Conference on Model DrivenEngineering Languages and Systems (pp 276ndash285)

Tahmid A Nahar N amp Sakib K (2016) Understanding theevolution of code smells by observing code smell clusters In23rd IEEE International Conference on Software AnalysisEvolution and Reengineering (Vol 4 pp 8ndash11)

Thomas G Norman H Christian D amp Stefan K (2016)Artshop A continuous integration and quality assessmentframework for model-based software artifacts In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 13ndash22)

Toulmeacute A amp Inc I (2006) Presentation of EMF Compareutility In Eclipse Modeling Symposium (pp 1ndash8)

Tran Q M amp Dziobek C (2013) Approach to constructingand maintaining Simulink models based on the use of trans-formationrefactoring and generation operations In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 1ndash12)

Tufano M Palomba F Bavota G Oliveto R Di Penta MDe Lucia A amp Poshyvanyk D (2015) When and why yourcode starts to smell bad In 37th ACMIEEE InternationalConference on Software Engineering (Vol 1 pp 403ndash414)

Van Emden E amp Moonen L (2002) Java quality assuranceby detecting code smells In Proceedings of the 9th WorkingConference on Reverse Engineering (pp 97ndash106)

Zaman S Adams B amp Hassan A E (2012) A qualitativestudy on performance bugs In 9th IEEE Working Conferenceon Mining Software Repositories (pp 199ndash208)

Zhao X amp Gray J (2019) BESMER An approach for badsmells summarization in systems models In Models andEvolution Workshop at the 22nd ACMIEEE InternationalConference on Model Driven Engineering Languages andSystems (pp 304ndash313)

About the authorsSaheed Popoola is a PhD candidate in the Department of Com-puter Science at the University of Alabama His doctoral re-search deals with the evolution and design analysis of systemsmodels His broad research interests deals with the applicationof software engineering techniques to address software devel-opment challenges in systems engineering Prior to joiningthe University of Alabama he was a member of the Enter-prise Systems Group University of York where he obtainedan MSc (By Research) in Computer Science under the su-

14 Popoola et al

dependencies Figure 4 shows a simplified view of the meta-model

We simplify the amount of effort required to translate a badsmell into an efficient query method via an extensible and care-fully designed metamodel that captures the relationships amongthe elements in a LabVIEW model The metamodel supportsOOP concepts such as inheritance thereby making it possible togroup related elements The selected bad smells focus on struc-tures and certain characteristics that have been known to suggesta bad design The constructed metamodel captures these struc-tures and characteristics thereby simplifying the query neededto identify these properties in a LabVIEW model The query toidentify smells has to be manually constructed but the detectionand historical evolution of smells based on the queries has beenautomated A sample query was developed for each of the badsmells (from Section 5) to detect the presence of the bad smellsin the repositories It should be noted that the metamodel canbe used to simplify the query for detecting any arbitrary badsmells that focus on the structural properties of a LabVIEWmodel Furthermore because the LabVIEW metamodel wasdeveloped by curating sample models it is possible that themetamodel may not cover all possible features in a LabVIEWmodel However the metamodel is open-source and extensibletherefore it can be easily extended by anyone to accommodatemore features that are not currently covered

For Large Variables we extracted the total number of vari-ables in each model The No Wait in a Loop bad smell wasextracted by examining all of the loops (Both While Loop andFor Loop) and recursively checking for the presence of a Waitelement in any of the loops The Build Array in a Loop and theString Concatenation in Loop bad smells were identified in asimilar way to the No Wait in a Loop smell except that the BuildArray and String Concatenation elements were respectively theobject of interest in the loops The Excessive Property Nodesbad smell was extracted via the Property Node type defined inthe metamodel Multiple Nested Loops was extracted by search-ing for all the loop structures that have another loop structureembedded within them Finally instances of the Deeply NestedSubsystem Hierarchy smell was detected by first extracting allthe subVIrsquos in a Model and then searching through the extractedsubVIs for any one that has at least one subVI In LabVIEW asubVI is usually a complete VI in another file that is called byits parent VI

The correctness of the queries has been manually verifiedby randomly selecting four models that return a positive resultfor a smell and four models where the execution of a query didnot detect instances of the smell This process was repeatedfor all of the seven queries The only exception was the BuildArray in the Loop smell where the execution of the query de-tected instances of the smell in only two models Thereforeonly two models were used to verify the positive result Theresults of the verification process shows that the queries were100 correct The complete open-source LabVIEW metamodelmodel interpreter and all of the seven queries developed to ex-tract the bad smells are publicly available online (please seehttpbitlyLMeta)

Repo Properties

URL for Repository ofModels

ofElements

Repo 1 httpsgithubcomniwebvi-examples

1 680

Repo 2 httpsgithubcomJKISoftwareJKI-State-Machine-NXG

10 5537

Repo 3 httpsgithubcomnilabview-nxg-jenkins-build

14 270

Repo 4 httpsgithubcomrajsite webvi-hack

11 654

Repo 5 httpsgithubcomprestwickcustomizing-webvis

5 1650

Repo 6 httpsgithubcomtherinoyLabVIEW-NXG-BL11W-Web-App-Project

3 1312

Repo 7 httpsgithubcomnavinsubrama-nidevelop-and-deploy-WebVI

15 487

Repo 8 httpsgithubcomwimtormansLabVIEWRaspber-ryPI_IndoorMonitoring

8 1947

Repo 9 httpsgithubcomeyesonvisniweek2019-webVI-hands-on

3 538

Repo 10 httpsgithubcomdoczhivagoDownloadUploadAFileWebVI

6 171

Table 1 Overview of 10 Repositories and Identified Smells

7 Research Questions and AnalysisWe developed three research questions to study the evolutionof LabVIEW models The research questions deal with theintroduction and prevalence of bad smells in LabVIEW reposi-tories as well as the structural changes to models that are likelyto introduce bad smells The research questions which werediscussed in more detail in Section 4 are as follows

RQ1 How prevalent are bad smells in a LabVIEW model

RQ2 When are bad smells introduced in a LabVIEW model

RQ3 What is the relationship between the bad smells and struc-tural changes made to the models

To answer these research questions a preliminary investigationand analysis of the selected seven bad smells was performedon 81 LabVIEW models stored in 10 GitHub repositories ofvarying size and complexity An initial set of selected projectswere identified and the models embedded in these projects werevalidated against our LabVIEW metamodel The metamodelwas also updated to accommodate new relationships that wereobserved across the 10 public projects containing 81 LabVIEWmodels Table 1 gives an overview of the repositories Thefollowing subsections address each of the research questions

8 Popoola et al

Figure 4 A simplified LabVIEW metamodel (Popoola amp Gray 2019)

and provides an in-depth study of the evolution of bad smells inLabVIEW models

71 Prevalence of Bad Smells in LabVIEW Models

To answer the question related to the prevalence of bad smellsin LabVIEW models we queried the repository to check for thepresence of each of the seven selected bad smells in the iden-tified repositories Table 2 shows that most of the repositoriescontain instances of 2 or 3 kinds of smells across the life cycleof the models embedded in the repositories Furthermore thesize and complexity of the models embedded in the repositoriesdoes not seem to affect the possibility of the models containinga bad smell This may also validate the hypothesis that thedevelopers are not very familiar with software engineering de-sign principles because bad smells are often associated with badsoftware engineering practices (Van Emden amp Moonen 2002)Table 2 gives a breakdown of the presence of each of the badsmells in the life cycle of the models stored in the repositories

72 When are Bad Smells Introduced

The introduction and consequent increasedecrease of instancesof a bad smell is very important to understand the impact ofmaintenance activities in the life cycle of LabVIEW modelsTo answer this research question we first checked for wheninstances of each smell was first detected in each repositoryThe results show that 55 of the smells were introduced inthe first version of the repositories 17 of the smells wereintroduced in the second version and the remaining 27 wereintroduced in other versions This result shows that bad smellsare introduced at various stages of the software developmentprocess but most of the smells were introduced at the initialversion This suggests that software maintenance activities arenot solely responsible for the introduction of bad smells Figure5 summarizes the results corresponding to when a bad smell isintroduced

The number of bad smell instances also tends to increasesteadily over time and then decline after a peak period Figures6 7 8 9 shows the evolution of four types of smells across theversion history of the repositories It should be noted that thesmells String Concatenation in Loop Deeply Nested Subsys-tem Hierarchy and Build Array in a Loop have been omittedfrom the figures This is because only trivial changes wereobserved in the number of smell instances across the versionhistory of models in all the repositories Furthermore some ofthe repositories have less than 7 versions hence there may bea constant value from the last version number to the ldquocurrentversionrdquo specified in the figures We also analysed the evolutionof all the smells in each repository as the size of the modelsincreased While the full data is provided in the GitHub reposi-tory we provide a sample analysis of repository 2 Figure 10gives an overview of the evolution of smells in repository 2while Figure 11 shows the increasing size of the models in therepository within the same period However it should be notedthat while the overall size of the models increased throughoutthe life cycle of repository 2 the number of model elementsactually decreased in versions after the peak period

73 Structural Changes Related to Bad SmellsThe evolution of a model necessitates the continuous introduc-tion of new changes to the model These changes are neededfor various reasons such as adapting the model to new require-ments fixing a bug or making the model easier to understandHowever these changes may introduce new unintended smellswithin the model This phase of the research identifies the setof structural changes that led to the introduction increase orreduction of bad smells in the models

We used EMFCompare (Toulmeacute amp Inc 2006) to extract thestructural differences between different versions of LabVIEWModels EMFCompare is a model differencing framework forextracting differences between two or three sets of models Two-way differencing involves the direct comparison of two models

Evolution of Bad Smells in LabVIEW Graphical Models 9

Repo Smells LargeVariables

No Wait Build Array PropertyNode

String Con-catenation

Nested Loop Nested Sub-system

Repo 1 yes yes no no no yes yes

Repo 2 yes yes no yes no yes yes

Repo 3 no no no yes no no no

Repo 4 yes yes no yes no no no

Repo 5 yes yes no yes no yes no

Repo 6 no yes yes no yes no no

Repo 7 yes yes no yes no yes no

Repo 8 yes yes no yes no no no

Repo 9 yes yes no no no no no

Repo 10 yes yes no yes no no no

Table 2 Detection of Each Smell across 10 Repositories

Figure 5 Smell Introduction across Repositories

10 Popoola et al

Figure 6 Evolution of Multiple Nested Loops Across VersionHistory of LabVIEW Models

Figure 7 Evolution of No Wait in a Loop Across VersionHistory of LabVIEW Models

Figure 8 Evolution of Excessive Property Nodes AcrossVersion History of LabVIEW Models

Figure 9 Evolution of Large Variables Across Version Historyof LabVIEW Models

Figure 10 Evolution of Bad Smells in Repository 2

Figure 11 Evolution of the Model Size in Repository 2

Evolution of Bad Smells in LabVIEW Graphical Models 11

RepoDiffKind

AvgADD

AvgDELETE

AvgCHANGE

AvgMOVE

Repo 1 322 0 0 0

Repo 2 998 0 0 0

Repo 3 270 0 0 0

Repo 4 2288 15 122 106

Repo 5 4532 521 824 79

Repo 6 658 1 5 0

Repo 7 487 0 0 0

Repo 8 894 25 105 15

Repo 9 538 0 0 0

Repo 10 159 0 0 0

Table 3 Average Number of Difference Types Across VersionHistory

while three-way differencing involves the comparison of twomodels based on their evolution via a third common modelFor this study we used the two-way differencing for directcomparison between models in a specific version and models inthe succeeding version EMFCompare supports four types ofchanges between two sets of models ADD to indicate additionof new elements DELETE to show removal of existing elementsCHANGE to indicate the change of attribute values and MOVEto indicate reordering of elements

To analyse the differences in models across various versionseach version of the models in the identified repository was ex-tracted converted to an XMI format and then compared with itssucceeding version using EMFCompare for efficient extractionof changes between the versions These sets of changes werethen aggregated and analysed for all versions in a repositoryThis analysis makes it easy to understand the changes that ne-cessitate the evolution of LabVIEW programs These structuralchanges to the models were then mapped to the changes in thebad smells exhibited by such models

The results of the analysis of changes across the versionhistory of LabVIEW models in the 10 repositories show thatthe majority of the changes involved addition of new elementsTable 3 shows the average number of modifications that areperformed across each version in the repositories

The addition of new elements to succeeding versions alsocorresponds to increasing instances of smells in the repositoryFurthermore versions with a lower number of smell instancesare also associated with a higher number of deletions and at-tribute changes than number of additions Figure 12 shows thetrend of different kinds of changes in repository 2 It should benoted that there was a sharp increase in the number of deletionsand re-orderings (move) of elements There was also a decrease

Figure 12 Evolution of Change Kinds in Repository 2

in the number of additions This corresponds to the decrease inbad smells shown in Figures 6 to 9

8 Threats to ValidityThis paper presents an analysis of bad smells in LabVIEW mod-els Although a number of steps have been taken to ensure thatthe results presented in this paper are valid and generalizablewe have identified at least four main threats to the validity ofthe results presented in this paper

A Small sample size The sample size of the models used inthis evaluation is rather small and thus the results may notbe generalizable to all LabVIEW models The small sam-ple size is due to the relative young age of the LabVIEWNXG platform and the limited number of open-sourcerepositories that contain LAbVIEW NXG models

B Author demographics We do not know the experienceof the engineers who published the selected projects andhow their experience affected the quality of the selectedmodels It is possible that more experienced developersare able to produce models with higher quality and fewerinstances of bad smells Unfortunately information aboutthe author demographics could not be extracted from theGitHub repositories used in this study

C LabVIEW-specific smells and models The paper only con-siders LabVIEW models for the evaluation and some ofthe smells are specific to the LabVIEW environment Fur-thermore even though some of the smells are applicable toother systems modelling or data acquisition platforms thispaper only considers the effect of the smells on LabVIEWmodels Hence the results may not be generalizable for allsystems modeling or data acquisition environments

D Correctness of the queries The results presented in thispaper depend on the correctness of the queries used toidentify instances of bad smells in the LabVIEW modelsAlthough we have ensured that the queries in this paperare correct it may be possible that a new query generatessome false negatives or false positives

12 Popoola et al

We plan to address each of these concerns as part of futurework However we believe that the results reported in thispaper provide significant insight into the general evolution ofbad smells in systems models

9 Related WorkMuch work exists on bad smell identification in text-based lan-guages Chatzigeorgiou et al (Chatzigeorgiou amp Manakos2014) investigated the presence and persistence of bad smellsin two open source projects Their results show that bad smellsare introduced at the initial version and often persist up to thecurrent version of a project Furthermore the few eliminatedsmells often occur from a side effect of routine maintenanceactivities instead of a refactoring activity that specifically targetsthe removal of the smell Olbrich et al (Olbrich et al 2009)also conducted a similar study and concluded that code withsmells are more prone to frequent changes than projects that donot contain bad smells Tahmid et al (Tahmid et al 2016) alsopresented an approach for analysing bad smells in code reposi-tories based on the relationships between different bad smellsand the architecture of the source code The approach simplifiesthe development of clusters of bad smells embedded in the codefor easy refactoring However all of these approaches focuson text-based languages and none of them considered systemsmodels developed via graphical languages

Some work has been done to identify bad smells in graphicallanguages Simulink provides an interactive graphical envi-ronment for modeling simulating and analysing of dynamicsystems It includes a comprehensive library of predefinedblocks to be used to construct graphical models of systems us-ing drag-and-drop mouse operations Bad smells in Simulinksystems models are identified by Gerlitz et al (Gerlitz et al2015) In this work the authors summarized 21 bad smellsinto 5 categories name partition interface signal flow andsignal structure Two tools Artshopr (Thomas et al 2016) andSLRefactor (Tran amp Dziobek 2013) were implemented to ad-dress these bad smells Stephan and Cordy adopted near-misscross-clone detection to find instances of antipatterns derivedfrom the literature in public Simulink projects (Stephan amp Cordy2015)

Chambers and Scaffidi (Chambers amp Scaffidi 2013) devel-oped an approach for identifying bad smells in systems modelsvia interviews with modeling experts In our own earlier workwe developed an approach for identifying bad smells in Lab-VIEW models from an end-usersrsquo perspective by mining onlineforum posts (Zhao amp Gray 2019) However both (Chambersamp Scaffidi 2013) and (Zhao amp Gray 2019) do not investigatethe presence of the identified smells in code repositories nor dothey study the evolution of such smells This paper extends theliterature by proposing techniques for identifying bad smells ingraphical languages and analysing the evolution of such smellsacross the version history of the software systems developed

10 Conclusion and Future WorkWe introduced a semi-automated approach for detecting andanalysing bad smells in LabVIEW models via user-defined

queries The support for inheritance relationships in the Lab-VIEW metamodel was exploited to simplify the development ofuser queries to detect known bad smells from systems modelsThe approach has been evaluated on 69 models in 10 GitHubrepositories The evaluation process includes the analysis offour selected bad smells reported by end users The prelimi-nary results suggest that most smells are introduced in the earlyversions of a model and these smells often persist throughoutthe life cycle of the modeled system Furthermore most of theprojects contain three or four types of smells This may be anindication of the need for more automated analysis and refactor-ing support for systems engineers who may not be familiar withbad smell identification and refactoring

In the future we plan to carry out an extensive analysis onmore GitHub projects and other graphical modeling tools suchas Simulink The majority of the smells discussed in this paperare specific to LabVIEW hence we plan to cover more smellssuch as ldquoDuplicate Modelrdquo that can be generalizable to othergraphical modelling environments We also plan to conductqualitative studies that will complement the results presented inthis paper We will conduct studies to understand the contextin which bad smells are introduced the relationship betweenauthor demographics and bad smells and the level of consid-eration given to bad smells by LabVIEW developers Further-more we will implement and study the benefits of a refactoringmechanism to address the challenges of bad smells from theperspective of a systems engineer Finally we plan to improveour study to identify refactoring activities that specifically targetthe reduction of bad smells discover the impacts of bad smellson maintenance activities and highlight the differences in theanalysis of bad smells in graphical and textual languages

Acknowledgements

The authors would like to appreciate the contribution of DrTaylor Richeacute (National Instruments) and Dr Antonio Garcia-Dominguez (Aston University UK) for their help with generalquestions for LabVIEW and Hawk respectively We wouldalso like to thank the editors and reviewers for their time andinsightful feedback

References

Barmpis K Garciacutea-Domiacutenguez A Bagnato A amp AbherveA (2020) Monitoring model analytics over large repositorieswith hawk and measure In Model Management and Analyticsfor Large Scale Systems (pp 87ndash123) Elsevier

Barmpis K amp Kolovos D S (2014) Towards scalablequerying of large-scale models In 10th European Conferenceon Modelling Foundations and Applications (pp 35ndash50)

Bartelt C (2008) Consistence preserving model merge incollaborative development processes In Proceedings of theInternational Workshop on Comparison and Versioning ofSoftware Models (pp 13ndash18)

Carccedilao T (2014) Measuring and visualizing energy consump-tion within software code In IEEE Symposium on VisualLanguages and Human-Centric Computing (pp 181ndash182)

Evolution of Bad Smells in LabVIEW Graphical Models 13

Carccedilao T Cunha J Fernandes J P Pereira R amp Saraiva J(2014) Energy consumption detection in LabVIEW In IEEESymposium on Visual Languages and Human-Centric Com-puting Travel Support Competition httpwww4diuminhopt~jasResearchPapersnationalInstrumentspdf

Chambers C amp Scaffidi C (2013) Smell-driven performanceanalysis for end-user programmers In IEEE Symposiumon Visual Languages and Human Centric Computing (pp159ndash166)

Chatzigeorgiou A amp Manakos A (2014) Investigating theevolution of code smells in object-oriented systems Innova-tions in Systems and Software Engineering 10(1) 3ndash18

Exman I (2014) Linear software models standard modu-larity highlights residual coupling International Journal ofSoftware Engineering and Knowledge Engineering 24(02)183ndash210

Falcon J (2017) Facilitating modeling and simulation of com-plex systems through interoperable software In Keynote ad-dress at 20th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems

Gamma E Helm R Johnson R amp Vlissides J (1995) De-sign patterns Elements of reusable object-oriented softwareUSA Addison-Wesley Longman Publishing Co Inc

Garciacutea-Domiacutenguez A Bencomo N Parra-Ullauri J M ampGarciacutea-Paucar L H (2019) Querying and annotating modelhistories with time-aware patterns In 22nd ACMIEEE In-ternational Conference on Model Driven Engineering Lan-guages and Systems (pp 194ndash204)

Gerlitz T Tran Q M amp Dziobek C (2015) Detection andhandling of model smells for MATLABSimulink modelsIn Modeling in Automotive Software Engineering Workshopat the 18th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems (pp 13ndash22)

Johnson G W (1997) LabVIEW Graphical ProgrammingTata McGraw-Hill Education

Karunaratne M Tan C Kulkarni A Mitra T amp Peh L-S(2018) Dnestmap mapping deeply-nested loops on ultra-low power cgras In Proceedings of the 55th Annual DesignAutomation Conference (pp 1ndash6)

Loacutepez-Fernaacutendez J J Cuadrado J S Guerra E amp De Lara J(2015) Example-driven meta-model development Softwareand Systems Modeling 14(4) 1323ndash1347

Ludewig J (2003) Models in software engineeringndashAn intro-duction Software and Systems Modeling 2(1) 5ndash14

Olbrich S Cruzes D S Basili V amp Zazworka N (2009)The evolution and impact of code smells A case study oftwo open source systems In 3rd International Symposiumon Empirical Software Engineering and Measurement (pp390ndash400)

Opdyke W F (1992) Refactoring object-oriented frameworks(Unpublished doctoral dissertation) University of Illinois atUrbana-Champaign Champaign IL USA

Popoola S amp Gray J (2019) A LabVIEW metamodel forautomated analysis In International Conference on Com-putational Science and Computational Intelligence (p 1127-1132)

Quillereacute F Rajopadhye S amp Wilde D (2000) Generation of

efficient nested loops from polyhedra International Journalof Parallel Programming 28(5) 469ndash498

Robbes R Kamei Y amp Pinzger M (2017) Guest EditorialMining software repositories Empirical Software Engineer-ing 22(3) 1143ndash1145

Roberts D Opdyke W Beck K Fowler M amp Brant J(1999) Refactoring Improving the Design of Existing CodeAddison-Wesley Longman Publishing Boston

Services E (nd) Companies using labview httpsenlyftcomtechproductslabview (Accessed January 2020)

Stephan M amp Cordy J R (2015) Identification of Simulinkmodel antipattern instances using model clone detection In18th ACMIEEE International Conference on Model DrivenEngineering Languages and Systems (pp 276ndash285)

Tahmid A Nahar N amp Sakib K (2016) Understanding theevolution of code smells by observing code smell clusters In23rd IEEE International Conference on Software AnalysisEvolution and Reengineering (Vol 4 pp 8ndash11)

Thomas G Norman H Christian D amp Stefan K (2016)Artshop A continuous integration and quality assessmentframework for model-based software artifacts In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 13ndash22)

Toulmeacute A amp Inc I (2006) Presentation of EMF Compareutility In Eclipse Modeling Symposium (pp 1ndash8)

Tran Q M amp Dziobek C (2013) Approach to constructingand maintaining Simulink models based on the use of trans-formationrefactoring and generation operations In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 1ndash12)

Tufano M Palomba F Bavota G Oliveto R Di Penta MDe Lucia A amp Poshyvanyk D (2015) When and why yourcode starts to smell bad In 37th ACMIEEE InternationalConference on Software Engineering (Vol 1 pp 403ndash414)

Van Emden E amp Moonen L (2002) Java quality assuranceby detecting code smells In Proceedings of the 9th WorkingConference on Reverse Engineering (pp 97ndash106)

Zaman S Adams B amp Hassan A E (2012) A qualitativestudy on performance bugs In 9th IEEE Working Conferenceon Mining Software Repositories (pp 199ndash208)

Zhao X amp Gray J (2019) BESMER An approach for badsmells summarization in systems models In Models andEvolution Workshop at the 22nd ACMIEEE InternationalConference on Model Driven Engineering Languages andSystems (pp 304ndash313)

About the authorsSaheed Popoola is a PhD candidate in the Department of Com-puter Science at the University of Alabama His doctoral re-search deals with the evolution and design analysis of systemsmodels His broad research interests deals with the applicationof software engineering techniques to address software devel-opment challenges in systems engineering Prior to joiningthe University of Alabama he was a member of the Enter-prise Systems Group University of York where he obtainedan MSc (By Research) in Computer Science under the su-

14 Popoola et al

Figure 4 A simplified LabVIEW metamodel (Popoola amp Gray 2019)

and provides an in-depth study of the evolution of bad smells inLabVIEW models

71 Prevalence of Bad Smells in LabVIEW Models

To answer the question related to the prevalence of bad smellsin LabVIEW models we queried the repository to check for thepresence of each of the seven selected bad smells in the iden-tified repositories Table 2 shows that most of the repositoriescontain instances of 2 or 3 kinds of smells across the life cycleof the models embedded in the repositories Furthermore thesize and complexity of the models embedded in the repositoriesdoes not seem to affect the possibility of the models containinga bad smell This may also validate the hypothesis that thedevelopers are not very familiar with software engineering de-sign principles because bad smells are often associated with badsoftware engineering practices (Van Emden amp Moonen 2002)Table 2 gives a breakdown of the presence of each of the badsmells in the life cycle of the models stored in the repositories

72 When are Bad Smells Introduced

The introduction and consequent increasedecrease of instancesof a bad smell is very important to understand the impact ofmaintenance activities in the life cycle of LabVIEW modelsTo answer this research question we first checked for wheninstances of each smell was first detected in each repositoryThe results show that 55 of the smells were introduced inthe first version of the repositories 17 of the smells wereintroduced in the second version and the remaining 27 wereintroduced in other versions This result shows that bad smellsare introduced at various stages of the software developmentprocess but most of the smells were introduced at the initialversion This suggests that software maintenance activities arenot solely responsible for the introduction of bad smells Figure5 summarizes the results corresponding to when a bad smell isintroduced

The number of bad smell instances also tends to increasesteadily over time and then decline after a peak period Figures6 7 8 9 shows the evolution of four types of smells across theversion history of the repositories It should be noted that thesmells String Concatenation in Loop Deeply Nested Subsys-tem Hierarchy and Build Array in a Loop have been omittedfrom the figures This is because only trivial changes wereobserved in the number of smell instances across the versionhistory of models in all the repositories Furthermore some ofthe repositories have less than 7 versions hence there may bea constant value from the last version number to the ldquocurrentversionrdquo specified in the figures We also analysed the evolutionof all the smells in each repository as the size of the modelsincreased While the full data is provided in the GitHub reposi-tory we provide a sample analysis of repository 2 Figure 10gives an overview of the evolution of smells in repository 2while Figure 11 shows the increasing size of the models in therepository within the same period However it should be notedthat while the overall size of the models increased throughoutthe life cycle of repository 2 the number of model elementsactually decreased in versions after the peak period

73 Structural Changes Related to Bad SmellsThe evolution of a model necessitates the continuous introduc-tion of new changes to the model These changes are neededfor various reasons such as adapting the model to new require-ments fixing a bug or making the model easier to understandHowever these changes may introduce new unintended smellswithin the model This phase of the research identifies the setof structural changes that led to the introduction increase orreduction of bad smells in the models

We used EMFCompare (Toulmeacute amp Inc 2006) to extract thestructural differences between different versions of LabVIEWModels EMFCompare is a model differencing framework forextracting differences between two or three sets of models Two-way differencing involves the direct comparison of two models

Evolution of Bad Smells in LabVIEW Graphical Models 9

Repo Smells LargeVariables

No Wait Build Array PropertyNode

String Con-catenation

Nested Loop Nested Sub-system

Repo 1 yes yes no no no yes yes

Repo 2 yes yes no yes no yes yes

Repo 3 no no no yes no no no

Repo 4 yes yes no yes no no no

Repo 5 yes yes no yes no yes no

Repo 6 no yes yes no yes no no

Repo 7 yes yes no yes no yes no

Repo 8 yes yes no yes no no no

Repo 9 yes yes no no no no no

Repo 10 yes yes no yes no no no

Table 2 Detection of Each Smell across 10 Repositories

Figure 5 Smell Introduction across Repositories

10 Popoola et al

Figure 6 Evolution of Multiple Nested Loops Across VersionHistory of LabVIEW Models

Figure 7 Evolution of No Wait in a Loop Across VersionHistory of LabVIEW Models

Figure 8 Evolution of Excessive Property Nodes AcrossVersion History of LabVIEW Models

Figure 9 Evolution of Large Variables Across Version Historyof LabVIEW Models

Figure 10 Evolution of Bad Smells in Repository 2

Figure 11 Evolution of the Model Size in Repository 2

Evolution of Bad Smells in LabVIEW Graphical Models 11

RepoDiffKind

AvgADD

AvgDELETE

AvgCHANGE

AvgMOVE

Repo 1 322 0 0 0

Repo 2 998 0 0 0

Repo 3 270 0 0 0

Repo 4 2288 15 122 106

Repo 5 4532 521 824 79

Repo 6 658 1 5 0

Repo 7 487 0 0 0

Repo 8 894 25 105 15

Repo 9 538 0 0 0

Repo 10 159 0 0 0

Table 3 Average Number of Difference Types Across VersionHistory

while three-way differencing involves the comparison of twomodels based on their evolution via a third common modelFor this study we used the two-way differencing for directcomparison between models in a specific version and models inthe succeeding version EMFCompare supports four types ofchanges between two sets of models ADD to indicate additionof new elements DELETE to show removal of existing elementsCHANGE to indicate the change of attribute values and MOVEto indicate reordering of elements

To analyse the differences in models across various versionseach version of the models in the identified repository was ex-tracted converted to an XMI format and then compared with itssucceeding version using EMFCompare for efficient extractionof changes between the versions These sets of changes werethen aggregated and analysed for all versions in a repositoryThis analysis makes it easy to understand the changes that ne-cessitate the evolution of LabVIEW programs These structuralchanges to the models were then mapped to the changes in thebad smells exhibited by such models

The results of the analysis of changes across the versionhistory of LabVIEW models in the 10 repositories show thatthe majority of the changes involved addition of new elementsTable 3 shows the average number of modifications that areperformed across each version in the repositories

The addition of new elements to succeeding versions alsocorresponds to increasing instances of smells in the repositoryFurthermore versions with a lower number of smell instancesare also associated with a higher number of deletions and at-tribute changes than number of additions Figure 12 shows thetrend of different kinds of changes in repository 2 It should benoted that there was a sharp increase in the number of deletionsand re-orderings (move) of elements There was also a decrease

Figure 12 Evolution of Change Kinds in Repository 2

in the number of additions This corresponds to the decrease inbad smells shown in Figures 6 to 9

8 Threats to ValidityThis paper presents an analysis of bad smells in LabVIEW mod-els Although a number of steps have been taken to ensure thatthe results presented in this paper are valid and generalizablewe have identified at least four main threats to the validity ofthe results presented in this paper

A Small sample size The sample size of the models used inthis evaluation is rather small and thus the results may notbe generalizable to all LabVIEW models The small sam-ple size is due to the relative young age of the LabVIEWNXG platform and the limited number of open-sourcerepositories that contain LAbVIEW NXG models

B Author demographics We do not know the experienceof the engineers who published the selected projects andhow their experience affected the quality of the selectedmodels It is possible that more experienced developersare able to produce models with higher quality and fewerinstances of bad smells Unfortunately information aboutthe author demographics could not be extracted from theGitHub repositories used in this study

C LabVIEW-specific smells and models The paper only con-siders LabVIEW models for the evaluation and some ofthe smells are specific to the LabVIEW environment Fur-thermore even though some of the smells are applicable toother systems modelling or data acquisition platforms thispaper only considers the effect of the smells on LabVIEWmodels Hence the results may not be generalizable for allsystems modeling or data acquisition environments

D Correctness of the queries The results presented in thispaper depend on the correctness of the queries used toidentify instances of bad smells in the LabVIEW modelsAlthough we have ensured that the queries in this paperare correct it may be possible that a new query generatessome false negatives or false positives

12 Popoola et al

We plan to address each of these concerns as part of futurework However we believe that the results reported in thispaper provide significant insight into the general evolution ofbad smells in systems models

9 Related WorkMuch work exists on bad smell identification in text-based lan-guages Chatzigeorgiou et al (Chatzigeorgiou amp Manakos2014) investigated the presence and persistence of bad smellsin two open source projects Their results show that bad smellsare introduced at the initial version and often persist up to thecurrent version of a project Furthermore the few eliminatedsmells often occur from a side effect of routine maintenanceactivities instead of a refactoring activity that specifically targetsthe removal of the smell Olbrich et al (Olbrich et al 2009)also conducted a similar study and concluded that code withsmells are more prone to frequent changes than projects that donot contain bad smells Tahmid et al (Tahmid et al 2016) alsopresented an approach for analysing bad smells in code reposi-tories based on the relationships between different bad smellsand the architecture of the source code The approach simplifiesthe development of clusters of bad smells embedded in the codefor easy refactoring However all of these approaches focuson text-based languages and none of them considered systemsmodels developed via graphical languages

Some work has been done to identify bad smells in graphicallanguages Simulink provides an interactive graphical envi-ronment for modeling simulating and analysing of dynamicsystems It includes a comprehensive library of predefinedblocks to be used to construct graphical models of systems us-ing drag-and-drop mouse operations Bad smells in Simulinksystems models are identified by Gerlitz et al (Gerlitz et al2015) In this work the authors summarized 21 bad smellsinto 5 categories name partition interface signal flow andsignal structure Two tools Artshopr (Thomas et al 2016) andSLRefactor (Tran amp Dziobek 2013) were implemented to ad-dress these bad smells Stephan and Cordy adopted near-misscross-clone detection to find instances of antipatterns derivedfrom the literature in public Simulink projects (Stephan amp Cordy2015)

Chambers and Scaffidi (Chambers amp Scaffidi 2013) devel-oped an approach for identifying bad smells in systems modelsvia interviews with modeling experts In our own earlier workwe developed an approach for identifying bad smells in Lab-VIEW models from an end-usersrsquo perspective by mining onlineforum posts (Zhao amp Gray 2019) However both (Chambersamp Scaffidi 2013) and (Zhao amp Gray 2019) do not investigatethe presence of the identified smells in code repositories nor dothey study the evolution of such smells This paper extends theliterature by proposing techniques for identifying bad smells ingraphical languages and analysing the evolution of such smellsacross the version history of the software systems developed

10 Conclusion and Future WorkWe introduced a semi-automated approach for detecting andanalysing bad smells in LabVIEW models via user-defined

queries The support for inheritance relationships in the Lab-VIEW metamodel was exploited to simplify the development ofuser queries to detect known bad smells from systems modelsThe approach has been evaluated on 69 models in 10 GitHubrepositories The evaluation process includes the analysis offour selected bad smells reported by end users The prelimi-nary results suggest that most smells are introduced in the earlyversions of a model and these smells often persist throughoutthe life cycle of the modeled system Furthermore most of theprojects contain three or four types of smells This may be anindication of the need for more automated analysis and refactor-ing support for systems engineers who may not be familiar withbad smell identification and refactoring

In the future we plan to carry out an extensive analysis onmore GitHub projects and other graphical modeling tools suchas Simulink The majority of the smells discussed in this paperare specific to LabVIEW hence we plan to cover more smellssuch as ldquoDuplicate Modelrdquo that can be generalizable to othergraphical modelling environments We also plan to conductqualitative studies that will complement the results presented inthis paper We will conduct studies to understand the contextin which bad smells are introduced the relationship betweenauthor demographics and bad smells and the level of consid-eration given to bad smells by LabVIEW developers Further-more we will implement and study the benefits of a refactoringmechanism to address the challenges of bad smells from theperspective of a systems engineer Finally we plan to improveour study to identify refactoring activities that specifically targetthe reduction of bad smells discover the impacts of bad smellson maintenance activities and highlight the differences in theanalysis of bad smells in graphical and textual languages

Acknowledgements

The authors would like to appreciate the contribution of DrTaylor Richeacute (National Instruments) and Dr Antonio Garcia-Dominguez (Aston University UK) for their help with generalquestions for LabVIEW and Hawk respectively We wouldalso like to thank the editors and reviewers for their time andinsightful feedback

References

Barmpis K Garciacutea-Domiacutenguez A Bagnato A amp AbherveA (2020) Monitoring model analytics over large repositorieswith hawk and measure In Model Management and Analyticsfor Large Scale Systems (pp 87ndash123) Elsevier

Barmpis K amp Kolovos D S (2014) Towards scalablequerying of large-scale models In 10th European Conferenceon Modelling Foundations and Applications (pp 35ndash50)

Bartelt C (2008) Consistence preserving model merge incollaborative development processes In Proceedings of theInternational Workshop on Comparison and Versioning ofSoftware Models (pp 13ndash18)

Carccedilao T (2014) Measuring and visualizing energy consump-tion within software code In IEEE Symposium on VisualLanguages and Human-Centric Computing (pp 181ndash182)

Evolution of Bad Smells in LabVIEW Graphical Models 13

Carccedilao T Cunha J Fernandes J P Pereira R amp Saraiva J(2014) Energy consumption detection in LabVIEW In IEEESymposium on Visual Languages and Human-Centric Com-puting Travel Support Competition httpwww4diuminhopt~jasResearchPapersnationalInstrumentspdf

Chambers C amp Scaffidi C (2013) Smell-driven performanceanalysis for end-user programmers In IEEE Symposiumon Visual Languages and Human Centric Computing (pp159ndash166)

Chatzigeorgiou A amp Manakos A (2014) Investigating theevolution of code smells in object-oriented systems Innova-tions in Systems and Software Engineering 10(1) 3ndash18

Exman I (2014) Linear software models standard modu-larity highlights residual coupling International Journal ofSoftware Engineering and Knowledge Engineering 24(02)183ndash210

Falcon J (2017) Facilitating modeling and simulation of com-plex systems through interoperable software In Keynote ad-dress at 20th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems

Gamma E Helm R Johnson R amp Vlissides J (1995) De-sign patterns Elements of reusable object-oriented softwareUSA Addison-Wesley Longman Publishing Co Inc

Garciacutea-Domiacutenguez A Bencomo N Parra-Ullauri J M ampGarciacutea-Paucar L H (2019) Querying and annotating modelhistories with time-aware patterns In 22nd ACMIEEE In-ternational Conference on Model Driven Engineering Lan-guages and Systems (pp 194ndash204)

Gerlitz T Tran Q M amp Dziobek C (2015) Detection andhandling of model smells for MATLABSimulink modelsIn Modeling in Automotive Software Engineering Workshopat the 18th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems (pp 13ndash22)

Johnson G W (1997) LabVIEW Graphical ProgrammingTata McGraw-Hill Education

Karunaratne M Tan C Kulkarni A Mitra T amp Peh L-S(2018) Dnestmap mapping deeply-nested loops on ultra-low power cgras In Proceedings of the 55th Annual DesignAutomation Conference (pp 1ndash6)

Loacutepez-Fernaacutendez J J Cuadrado J S Guerra E amp De Lara J(2015) Example-driven meta-model development Softwareand Systems Modeling 14(4) 1323ndash1347

Ludewig J (2003) Models in software engineeringndashAn intro-duction Software and Systems Modeling 2(1) 5ndash14

Olbrich S Cruzes D S Basili V amp Zazworka N (2009)The evolution and impact of code smells A case study oftwo open source systems In 3rd International Symposiumon Empirical Software Engineering and Measurement (pp390ndash400)

Opdyke W F (1992) Refactoring object-oriented frameworks(Unpublished doctoral dissertation) University of Illinois atUrbana-Champaign Champaign IL USA

Popoola S amp Gray J (2019) A LabVIEW metamodel forautomated analysis In International Conference on Com-putational Science and Computational Intelligence (p 1127-1132)

Quillereacute F Rajopadhye S amp Wilde D (2000) Generation of

efficient nested loops from polyhedra International Journalof Parallel Programming 28(5) 469ndash498

Robbes R Kamei Y amp Pinzger M (2017) Guest EditorialMining software repositories Empirical Software Engineer-ing 22(3) 1143ndash1145

Roberts D Opdyke W Beck K Fowler M amp Brant J(1999) Refactoring Improving the Design of Existing CodeAddison-Wesley Longman Publishing Boston

Services E (nd) Companies using labview httpsenlyftcomtechproductslabview (Accessed January 2020)

Stephan M amp Cordy J R (2015) Identification of Simulinkmodel antipattern instances using model clone detection In18th ACMIEEE International Conference on Model DrivenEngineering Languages and Systems (pp 276ndash285)

Tahmid A Nahar N amp Sakib K (2016) Understanding theevolution of code smells by observing code smell clusters In23rd IEEE International Conference on Software AnalysisEvolution and Reengineering (Vol 4 pp 8ndash11)

Thomas G Norman H Christian D amp Stefan K (2016)Artshop A continuous integration and quality assessmentframework for model-based software artifacts In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 13ndash22)

Toulmeacute A amp Inc I (2006) Presentation of EMF Compareutility In Eclipse Modeling Symposium (pp 1ndash8)

Tran Q M amp Dziobek C (2013) Approach to constructingand maintaining Simulink models based on the use of trans-formationrefactoring and generation operations In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 1ndash12)

Tufano M Palomba F Bavota G Oliveto R Di Penta MDe Lucia A amp Poshyvanyk D (2015) When and why yourcode starts to smell bad In 37th ACMIEEE InternationalConference on Software Engineering (Vol 1 pp 403ndash414)

Van Emden E amp Moonen L (2002) Java quality assuranceby detecting code smells In Proceedings of the 9th WorkingConference on Reverse Engineering (pp 97ndash106)

Zaman S Adams B amp Hassan A E (2012) A qualitativestudy on performance bugs In 9th IEEE Working Conferenceon Mining Software Repositories (pp 199ndash208)

Zhao X amp Gray J (2019) BESMER An approach for badsmells summarization in systems models In Models andEvolution Workshop at the 22nd ACMIEEE InternationalConference on Model Driven Engineering Languages andSystems (pp 304ndash313)

About the authorsSaheed Popoola is a PhD candidate in the Department of Com-puter Science at the University of Alabama His doctoral re-search deals with the evolution and design analysis of systemsmodels His broad research interests deals with the applicationof software engineering techniques to address software devel-opment challenges in systems engineering Prior to joiningthe University of Alabama he was a member of the Enter-prise Systems Group University of York where he obtainedan MSc (By Research) in Computer Science under the su-

14 Popoola et al

Repo Smells LargeVariables

No Wait Build Array PropertyNode

String Con-catenation

Nested Loop Nested Sub-system

Repo 1 yes yes no no no yes yes

Repo 2 yes yes no yes no yes yes

Repo 3 no no no yes no no no

Repo 4 yes yes no yes no no no

Repo 5 yes yes no yes no yes no

Repo 6 no yes yes no yes no no

Repo 7 yes yes no yes no yes no

Repo 8 yes yes no yes no no no

Repo 9 yes yes no no no no no

Repo 10 yes yes no yes no no no

Table 2 Detection of Each Smell across 10 Repositories

Figure 5 Smell Introduction across Repositories

10 Popoola et al

Figure 6 Evolution of Multiple Nested Loops Across VersionHistory of LabVIEW Models

Figure 7 Evolution of No Wait in a Loop Across VersionHistory of LabVIEW Models

Figure 8 Evolution of Excessive Property Nodes AcrossVersion History of LabVIEW Models

Figure 9 Evolution of Large Variables Across Version Historyof LabVIEW Models

Figure 10 Evolution of Bad Smells in Repository 2

Figure 11 Evolution of the Model Size in Repository 2

Evolution of Bad Smells in LabVIEW Graphical Models 11

RepoDiffKind

AvgADD

AvgDELETE

AvgCHANGE

AvgMOVE

Repo 1 322 0 0 0

Repo 2 998 0 0 0

Repo 3 270 0 0 0

Repo 4 2288 15 122 106

Repo 5 4532 521 824 79

Repo 6 658 1 5 0

Repo 7 487 0 0 0

Repo 8 894 25 105 15

Repo 9 538 0 0 0

Repo 10 159 0 0 0

Table 3 Average Number of Difference Types Across VersionHistory

while three-way differencing involves the comparison of twomodels based on their evolution via a third common modelFor this study we used the two-way differencing for directcomparison between models in a specific version and models inthe succeeding version EMFCompare supports four types ofchanges between two sets of models ADD to indicate additionof new elements DELETE to show removal of existing elementsCHANGE to indicate the change of attribute values and MOVEto indicate reordering of elements

To analyse the differences in models across various versionseach version of the models in the identified repository was ex-tracted converted to an XMI format and then compared with itssucceeding version using EMFCompare for efficient extractionof changes between the versions These sets of changes werethen aggregated and analysed for all versions in a repositoryThis analysis makes it easy to understand the changes that ne-cessitate the evolution of LabVIEW programs These structuralchanges to the models were then mapped to the changes in thebad smells exhibited by such models

The results of the analysis of changes across the versionhistory of LabVIEW models in the 10 repositories show thatthe majority of the changes involved addition of new elementsTable 3 shows the average number of modifications that areperformed across each version in the repositories

The addition of new elements to succeeding versions alsocorresponds to increasing instances of smells in the repositoryFurthermore versions with a lower number of smell instancesare also associated with a higher number of deletions and at-tribute changes than number of additions Figure 12 shows thetrend of different kinds of changes in repository 2 It should benoted that there was a sharp increase in the number of deletionsand re-orderings (move) of elements There was also a decrease

Figure 12 Evolution of Change Kinds in Repository 2

in the number of additions This corresponds to the decrease inbad smells shown in Figures 6 to 9

8 Threats to ValidityThis paper presents an analysis of bad smells in LabVIEW mod-els Although a number of steps have been taken to ensure thatthe results presented in this paper are valid and generalizablewe have identified at least four main threats to the validity ofthe results presented in this paper

A Small sample size The sample size of the models used inthis evaluation is rather small and thus the results may notbe generalizable to all LabVIEW models The small sam-ple size is due to the relative young age of the LabVIEWNXG platform and the limited number of open-sourcerepositories that contain LAbVIEW NXG models

B Author demographics We do not know the experienceof the engineers who published the selected projects andhow their experience affected the quality of the selectedmodels It is possible that more experienced developersare able to produce models with higher quality and fewerinstances of bad smells Unfortunately information aboutthe author demographics could not be extracted from theGitHub repositories used in this study

C LabVIEW-specific smells and models The paper only con-siders LabVIEW models for the evaluation and some ofthe smells are specific to the LabVIEW environment Fur-thermore even though some of the smells are applicable toother systems modelling or data acquisition platforms thispaper only considers the effect of the smells on LabVIEWmodels Hence the results may not be generalizable for allsystems modeling or data acquisition environments

D Correctness of the queries The results presented in thispaper depend on the correctness of the queries used toidentify instances of bad smells in the LabVIEW modelsAlthough we have ensured that the queries in this paperare correct it may be possible that a new query generatessome false negatives or false positives

12 Popoola et al

We plan to address each of these concerns as part of futurework However we believe that the results reported in thispaper provide significant insight into the general evolution ofbad smells in systems models

9 Related WorkMuch work exists on bad smell identification in text-based lan-guages Chatzigeorgiou et al (Chatzigeorgiou amp Manakos2014) investigated the presence and persistence of bad smellsin two open source projects Their results show that bad smellsare introduced at the initial version and often persist up to thecurrent version of a project Furthermore the few eliminatedsmells often occur from a side effect of routine maintenanceactivities instead of a refactoring activity that specifically targetsthe removal of the smell Olbrich et al (Olbrich et al 2009)also conducted a similar study and concluded that code withsmells are more prone to frequent changes than projects that donot contain bad smells Tahmid et al (Tahmid et al 2016) alsopresented an approach for analysing bad smells in code reposi-tories based on the relationships between different bad smellsand the architecture of the source code The approach simplifiesthe development of clusters of bad smells embedded in the codefor easy refactoring However all of these approaches focuson text-based languages and none of them considered systemsmodels developed via graphical languages

Some work has been done to identify bad smells in graphicallanguages Simulink provides an interactive graphical envi-ronment for modeling simulating and analysing of dynamicsystems It includes a comprehensive library of predefinedblocks to be used to construct graphical models of systems us-ing drag-and-drop mouse operations Bad smells in Simulinksystems models are identified by Gerlitz et al (Gerlitz et al2015) In this work the authors summarized 21 bad smellsinto 5 categories name partition interface signal flow andsignal structure Two tools Artshopr (Thomas et al 2016) andSLRefactor (Tran amp Dziobek 2013) were implemented to ad-dress these bad smells Stephan and Cordy adopted near-misscross-clone detection to find instances of antipatterns derivedfrom the literature in public Simulink projects (Stephan amp Cordy2015)

Chambers and Scaffidi (Chambers amp Scaffidi 2013) devel-oped an approach for identifying bad smells in systems modelsvia interviews with modeling experts In our own earlier workwe developed an approach for identifying bad smells in Lab-VIEW models from an end-usersrsquo perspective by mining onlineforum posts (Zhao amp Gray 2019) However both (Chambersamp Scaffidi 2013) and (Zhao amp Gray 2019) do not investigatethe presence of the identified smells in code repositories nor dothey study the evolution of such smells This paper extends theliterature by proposing techniques for identifying bad smells ingraphical languages and analysing the evolution of such smellsacross the version history of the software systems developed

10 Conclusion and Future WorkWe introduced a semi-automated approach for detecting andanalysing bad smells in LabVIEW models via user-defined

queries The support for inheritance relationships in the Lab-VIEW metamodel was exploited to simplify the development ofuser queries to detect known bad smells from systems modelsThe approach has been evaluated on 69 models in 10 GitHubrepositories The evaluation process includes the analysis offour selected bad smells reported by end users The prelimi-nary results suggest that most smells are introduced in the earlyversions of a model and these smells often persist throughoutthe life cycle of the modeled system Furthermore most of theprojects contain three or four types of smells This may be anindication of the need for more automated analysis and refactor-ing support for systems engineers who may not be familiar withbad smell identification and refactoring

In the future we plan to carry out an extensive analysis onmore GitHub projects and other graphical modeling tools suchas Simulink The majority of the smells discussed in this paperare specific to LabVIEW hence we plan to cover more smellssuch as ldquoDuplicate Modelrdquo that can be generalizable to othergraphical modelling environments We also plan to conductqualitative studies that will complement the results presented inthis paper We will conduct studies to understand the contextin which bad smells are introduced the relationship betweenauthor demographics and bad smells and the level of consid-eration given to bad smells by LabVIEW developers Further-more we will implement and study the benefits of a refactoringmechanism to address the challenges of bad smells from theperspective of a systems engineer Finally we plan to improveour study to identify refactoring activities that specifically targetthe reduction of bad smells discover the impacts of bad smellson maintenance activities and highlight the differences in theanalysis of bad smells in graphical and textual languages

Acknowledgements

The authors would like to appreciate the contribution of DrTaylor Richeacute (National Instruments) and Dr Antonio Garcia-Dominguez (Aston University UK) for their help with generalquestions for LabVIEW and Hawk respectively We wouldalso like to thank the editors and reviewers for their time andinsightful feedback

References

Barmpis K Garciacutea-Domiacutenguez A Bagnato A amp AbherveA (2020) Monitoring model analytics over large repositorieswith hawk and measure In Model Management and Analyticsfor Large Scale Systems (pp 87ndash123) Elsevier

Barmpis K amp Kolovos D S (2014) Towards scalablequerying of large-scale models In 10th European Conferenceon Modelling Foundations and Applications (pp 35ndash50)

Bartelt C (2008) Consistence preserving model merge incollaborative development processes In Proceedings of theInternational Workshop on Comparison and Versioning ofSoftware Models (pp 13ndash18)

Carccedilao T (2014) Measuring and visualizing energy consump-tion within software code In IEEE Symposium on VisualLanguages and Human-Centric Computing (pp 181ndash182)

Evolution of Bad Smells in LabVIEW Graphical Models 13

Carccedilao T Cunha J Fernandes J P Pereira R amp Saraiva J(2014) Energy consumption detection in LabVIEW In IEEESymposium on Visual Languages and Human-Centric Com-puting Travel Support Competition httpwww4diuminhopt~jasResearchPapersnationalInstrumentspdf

Chambers C amp Scaffidi C (2013) Smell-driven performanceanalysis for end-user programmers In IEEE Symposiumon Visual Languages and Human Centric Computing (pp159ndash166)

Chatzigeorgiou A amp Manakos A (2014) Investigating theevolution of code smells in object-oriented systems Innova-tions in Systems and Software Engineering 10(1) 3ndash18

Exman I (2014) Linear software models standard modu-larity highlights residual coupling International Journal ofSoftware Engineering and Knowledge Engineering 24(02)183ndash210

Falcon J (2017) Facilitating modeling and simulation of com-plex systems through interoperable software In Keynote ad-dress at 20th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems

Gamma E Helm R Johnson R amp Vlissides J (1995) De-sign patterns Elements of reusable object-oriented softwareUSA Addison-Wesley Longman Publishing Co Inc

Garciacutea-Domiacutenguez A Bencomo N Parra-Ullauri J M ampGarciacutea-Paucar L H (2019) Querying and annotating modelhistories with time-aware patterns In 22nd ACMIEEE In-ternational Conference on Model Driven Engineering Lan-guages and Systems (pp 194ndash204)

Gerlitz T Tran Q M amp Dziobek C (2015) Detection andhandling of model smells for MATLABSimulink modelsIn Modeling in Automotive Software Engineering Workshopat the 18th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems (pp 13ndash22)

Johnson G W (1997) LabVIEW Graphical ProgrammingTata McGraw-Hill Education

Karunaratne M Tan C Kulkarni A Mitra T amp Peh L-S(2018) Dnestmap mapping deeply-nested loops on ultra-low power cgras In Proceedings of the 55th Annual DesignAutomation Conference (pp 1ndash6)

Loacutepez-Fernaacutendez J J Cuadrado J S Guerra E amp De Lara J(2015) Example-driven meta-model development Softwareand Systems Modeling 14(4) 1323ndash1347

Ludewig J (2003) Models in software engineeringndashAn intro-duction Software and Systems Modeling 2(1) 5ndash14

Olbrich S Cruzes D S Basili V amp Zazworka N (2009)The evolution and impact of code smells A case study oftwo open source systems In 3rd International Symposiumon Empirical Software Engineering and Measurement (pp390ndash400)

Opdyke W F (1992) Refactoring object-oriented frameworks(Unpublished doctoral dissertation) University of Illinois atUrbana-Champaign Champaign IL USA

Popoola S amp Gray J (2019) A LabVIEW metamodel forautomated analysis In International Conference on Com-putational Science and Computational Intelligence (p 1127-1132)

Quillereacute F Rajopadhye S amp Wilde D (2000) Generation of

efficient nested loops from polyhedra International Journalof Parallel Programming 28(5) 469ndash498

Robbes R Kamei Y amp Pinzger M (2017) Guest EditorialMining software repositories Empirical Software Engineer-ing 22(3) 1143ndash1145

Roberts D Opdyke W Beck K Fowler M amp Brant J(1999) Refactoring Improving the Design of Existing CodeAddison-Wesley Longman Publishing Boston

Services E (nd) Companies using labview httpsenlyftcomtechproductslabview (Accessed January 2020)

Stephan M amp Cordy J R (2015) Identification of Simulinkmodel antipattern instances using model clone detection In18th ACMIEEE International Conference on Model DrivenEngineering Languages and Systems (pp 276ndash285)

Tahmid A Nahar N amp Sakib K (2016) Understanding theevolution of code smells by observing code smell clusters In23rd IEEE International Conference on Software AnalysisEvolution and Reengineering (Vol 4 pp 8ndash11)

Thomas G Norman H Christian D amp Stefan K (2016)Artshop A continuous integration and quality assessmentframework for model-based software artifacts In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 13ndash22)

Toulmeacute A amp Inc I (2006) Presentation of EMF Compareutility In Eclipse Modeling Symposium (pp 1ndash8)

Tran Q M amp Dziobek C (2013) Approach to constructingand maintaining Simulink models based on the use of trans-formationrefactoring and generation operations In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 1ndash12)

Tufano M Palomba F Bavota G Oliveto R Di Penta MDe Lucia A amp Poshyvanyk D (2015) When and why yourcode starts to smell bad In 37th ACMIEEE InternationalConference on Software Engineering (Vol 1 pp 403ndash414)

Van Emden E amp Moonen L (2002) Java quality assuranceby detecting code smells In Proceedings of the 9th WorkingConference on Reverse Engineering (pp 97ndash106)

Zaman S Adams B amp Hassan A E (2012) A qualitativestudy on performance bugs In 9th IEEE Working Conferenceon Mining Software Repositories (pp 199ndash208)

Zhao X amp Gray J (2019) BESMER An approach for badsmells summarization in systems models In Models andEvolution Workshop at the 22nd ACMIEEE InternationalConference on Model Driven Engineering Languages andSystems (pp 304ndash313)

About the authorsSaheed Popoola is a PhD candidate in the Department of Com-puter Science at the University of Alabama His doctoral re-search deals with the evolution and design analysis of systemsmodels His broad research interests deals with the applicationof software engineering techniques to address software devel-opment challenges in systems engineering Prior to joiningthe University of Alabama he was a member of the Enter-prise Systems Group University of York where he obtainedan MSc (By Research) in Computer Science under the su-

14 Popoola et al

Figure 6 Evolution of Multiple Nested Loops Across VersionHistory of LabVIEW Models

Figure 7 Evolution of No Wait in a Loop Across VersionHistory of LabVIEW Models

Figure 8 Evolution of Excessive Property Nodes AcrossVersion History of LabVIEW Models

Figure 9 Evolution of Large Variables Across Version Historyof LabVIEW Models

Figure 10 Evolution of Bad Smells in Repository 2

Figure 11 Evolution of the Model Size in Repository 2

Evolution of Bad Smells in LabVIEW Graphical Models 11

RepoDiffKind

AvgADD

AvgDELETE

AvgCHANGE

AvgMOVE

Repo 1 322 0 0 0

Repo 2 998 0 0 0

Repo 3 270 0 0 0

Repo 4 2288 15 122 106

Repo 5 4532 521 824 79

Repo 6 658 1 5 0

Repo 7 487 0 0 0

Repo 8 894 25 105 15

Repo 9 538 0 0 0

Repo 10 159 0 0 0

Table 3 Average Number of Difference Types Across VersionHistory

while three-way differencing involves the comparison of twomodels based on their evolution via a third common modelFor this study we used the two-way differencing for directcomparison between models in a specific version and models inthe succeeding version EMFCompare supports four types ofchanges between two sets of models ADD to indicate additionof new elements DELETE to show removal of existing elementsCHANGE to indicate the change of attribute values and MOVEto indicate reordering of elements

To analyse the differences in models across various versionseach version of the models in the identified repository was ex-tracted converted to an XMI format and then compared with itssucceeding version using EMFCompare for efficient extractionof changes between the versions These sets of changes werethen aggregated and analysed for all versions in a repositoryThis analysis makes it easy to understand the changes that ne-cessitate the evolution of LabVIEW programs These structuralchanges to the models were then mapped to the changes in thebad smells exhibited by such models

The results of the analysis of changes across the versionhistory of LabVIEW models in the 10 repositories show thatthe majority of the changes involved addition of new elementsTable 3 shows the average number of modifications that areperformed across each version in the repositories

The addition of new elements to succeeding versions alsocorresponds to increasing instances of smells in the repositoryFurthermore versions with a lower number of smell instancesare also associated with a higher number of deletions and at-tribute changes than number of additions Figure 12 shows thetrend of different kinds of changes in repository 2 It should benoted that there was a sharp increase in the number of deletionsand re-orderings (move) of elements There was also a decrease

Figure 12 Evolution of Change Kinds in Repository 2

in the number of additions This corresponds to the decrease inbad smells shown in Figures 6 to 9

8 Threats to ValidityThis paper presents an analysis of bad smells in LabVIEW mod-els Although a number of steps have been taken to ensure thatthe results presented in this paper are valid and generalizablewe have identified at least four main threats to the validity ofthe results presented in this paper

A Small sample size The sample size of the models used inthis evaluation is rather small and thus the results may notbe generalizable to all LabVIEW models The small sam-ple size is due to the relative young age of the LabVIEWNXG platform and the limited number of open-sourcerepositories that contain LAbVIEW NXG models

B Author demographics We do not know the experienceof the engineers who published the selected projects andhow their experience affected the quality of the selectedmodels It is possible that more experienced developersare able to produce models with higher quality and fewerinstances of bad smells Unfortunately information aboutthe author demographics could not be extracted from theGitHub repositories used in this study

C LabVIEW-specific smells and models The paper only con-siders LabVIEW models for the evaluation and some ofthe smells are specific to the LabVIEW environment Fur-thermore even though some of the smells are applicable toother systems modelling or data acquisition platforms thispaper only considers the effect of the smells on LabVIEWmodels Hence the results may not be generalizable for allsystems modeling or data acquisition environments

D Correctness of the queries The results presented in thispaper depend on the correctness of the queries used toidentify instances of bad smells in the LabVIEW modelsAlthough we have ensured that the queries in this paperare correct it may be possible that a new query generatessome false negatives or false positives

12 Popoola et al

We plan to address each of these concerns as part of futurework However we believe that the results reported in thispaper provide significant insight into the general evolution ofbad smells in systems models

9 Related WorkMuch work exists on bad smell identification in text-based lan-guages Chatzigeorgiou et al (Chatzigeorgiou amp Manakos2014) investigated the presence and persistence of bad smellsin two open source projects Their results show that bad smellsare introduced at the initial version and often persist up to thecurrent version of a project Furthermore the few eliminatedsmells often occur from a side effect of routine maintenanceactivities instead of a refactoring activity that specifically targetsthe removal of the smell Olbrich et al (Olbrich et al 2009)also conducted a similar study and concluded that code withsmells are more prone to frequent changes than projects that donot contain bad smells Tahmid et al (Tahmid et al 2016) alsopresented an approach for analysing bad smells in code reposi-tories based on the relationships between different bad smellsand the architecture of the source code The approach simplifiesthe development of clusters of bad smells embedded in the codefor easy refactoring However all of these approaches focuson text-based languages and none of them considered systemsmodels developed via graphical languages

Some work has been done to identify bad smells in graphicallanguages Simulink provides an interactive graphical envi-ronment for modeling simulating and analysing of dynamicsystems It includes a comprehensive library of predefinedblocks to be used to construct graphical models of systems us-ing drag-and-drop mouse operations Bad smells in Simulinksystems models are identified by Gerlitz et al (Gerlitz et al2015) In this work the authors summarized 21 bad smellsinto 5 categories name partition interface signal flow andsignal structure Two tools Artshopr (Thomas et al 2016) andSLRefactor (Tran amp Dziobek 2013) were implemented to ad-dress these bad smells Stephan and Cordy adopted near-misscross-clone detection to find instances of antipatterns derivedfrom the literature in public Simulink projects (Stephan amp Cordy2015)

Chambers and Scaffidi (Chambers amp Scaffidi 2013) devel-oped an approach for identifying bad smells in systems modelsvia interviews with modeling experts In our own earlier workwe developed an approach for identifying bad smells in Lab-VIEW models from an end-usersrsquo perspective by mining onlineforum posts (Zhao amp Gray 2019) However both (Chambersamp Scaffidi 2013) and (Zhao amp Gray 2019) do not investigatethe presence of the identified smells in code repositories nor dothey study the evolution of such smells This paper extends theliterature by proposing techniques for identifying bad smells ingraphical languages and analysing the evolution of such smellsacross the version history of the software systems developed

10 Conclusion and Future WorkWe introduced a semi-automated approach for detecting andanalysing bad smells in LabVIEW models via user-defined

queries The support for inheritance relationships in the Lab-VIEW metamodel was exploited to simplify the development ofuser queries to detect known bad smells from systems modelsThe approach has been evaluated on 69 models in 10 GitHubrepositories The evaluation process includes the analysis offour selected bad smells reported by end users The prelimi-nary results suggest that most smells are introduced in the earlyversions of a model and these smells often persist throughoutthe life cycle of the modeled system Furthermore most of theprojects contain three or four types of smells This may be anindication of the need for more automated analysis and refactor-ing support for systems engineers who may not be familiar withbad smell identification and refactoring

In the future we plan to carry out an extensive analysis onmore GitHub projects and other graphical modeling tools suchas Simulink The majority of the smells discussed in this paperare specific to LabVIEW hence we plan to cover more smellssuch as ldquoDuplicate Modelrdquo that can be generalizable to othergraphical modelling environments We also plan to conductqualitative studies that will complement the results presented inthis paper We will conduct studies to understand the contextin which bad smells are introduced the relationship betweenauthor demographics and bad smells and the level of consid-eration given to bad smells by LabVIEW developers Further-more we will implement and study the benefits of a refactoringmechanism to address the challenges of bad smells from theperspective of a systems engineer Finally we plan to improveour study to identify refactoring activities that specifically targetthe reduction of bad smells discover the impacts of bad smellson maintenance activities and highlight the differences in theanalysis of bad smells in graphical and textual languages

Acknowledgements

The authors would like to appreciate the contribution of DrTaylor Richeacute (National Instruments) and Dr Antonio Garcia-Dominguez (Aston University UK) for their help with generalquestions for LabVIEW and Hawk respectively We wouldalso like to thank the editors and reviewers for their time andinsightful feedback

References

Barmpis K Garciacutea-Domiacutenguez A Bagnato A amp AbherveA (2020) Monitoring model analytics over large repositorieswith hawk and measure In Model Management and Analyticsfor Large Scale Systems (pp 87ndash123) Elsevier

Barmpis K amp Kolovos D S (2014) Towards scalablequerying of large-scale models In 10th European Conferenceon Modelling Foundations and Applications (pp 35ndash50)

Bartelt C (2008) Consistence preserving model merge incollaborative development processes In Proceedings of theInternational Workshop on Comparison and Versioning ofSoftware Models (pp 13ndash18)

Carccedilao T (2014) Measuring and visualizing energy consump-tion within software code In IEEE Symposium on VisualLanguages and Human-Centric Computing (pp 181ndash182)

Evolution of Bad Smells in LabVIEW Graphical Models 13

Carccedilao T Cunha J Fernandes J P Pereira R amp Saraiva J(2014) Energy consumption detection in LabVIEW In IEEESymposium on Visual Languages and Human-Centric Com-puting Travel Support Competition httpwww4diuminhopt~jasResearchPapersnationalInstrumentspdf

Chambers C amp Scaffidi C (2013) Smell-driven performanceanalysis for end-user programmers In IEEE Symposiumon Visual Languages and Human Centric Computing (pp159ndash166)

Chatzigeorgiou A amp Manakos A (2014) Investigating theevolution of code smells in object-oriented systems Innova-tions in Systems and Software Engineering 10(1) 3ndash18

Exman I (2014) Linear software models standard modu-larity highlights residual coupling International Journal ofSoftware Engineering and Knowledge Engineering 24(02)183ndash210

Falcon J (2017) Facilitating modeling and simulation of com-plex systems through interoperable software In Keynote ad-dress at 20th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems

Gamma E Helm R Johnson R amp Vlissides J (1995) De-sign patterns Elements of reusable object-oriented softwareUSA Addison-Wesley Longman Publishing Co Inc

Garciacutea-Domiacutenguez A Bencomo N Parra-Ullauri J M ampGarciacutea-Paucar L H (2019) Querying and annotating modelhistories with time-aware patterns In 22nd ACMIEEE In-ternational Conference on Model Driven Engineering Lan-guages and Systems (pp 194ndash204)

Gerlitz T Tran Q M amp Dziobek C (2015) Detection andhandling of model smells for MATLABSimulink modelsIn Modeling in Automotive Software Engineering Workshopat the 18th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems (pp 13ndash22)

Johnson G W (1997) LabVIEW Graphical ProgrammingTata McGraw-Hill Education

Karunaratne M Tan C Kulkarni A Mitra T amp Peh L-S(2018) Dnestmap mapping deeply-nested loops on ultra-low power cgras In Proceedings of the 55th Annual DesignAutomation Conference (pp 1ndash6)

Loacutepez-Fernaacutendez J J Cuadrado J S Guerra E amp De Lara J(2015) Example-driven meta-model development Softwareand Systems Modeling 14(4) 1323ndash1347

Ludewig J (2003) Models in software engineeringndashAn intro-duction Software and Systems Modeling 2(1) 5ndash14

Olbrich S Cruzes D S Basili V amp Zazworka N (2009)The evolution and impact of code smells A case study oftwo open source systems In 3rd International Symposiumon Empirical Software Engineering and Measurement (pp390ndash400)

Opdyke W F (1992) Refactoring object-oriented frameworks(Unpublished doctoral dissertation) University of Illinois atUrbana-Champaign Champaign IL USA

Popoola S amp Gray J (2019) A LabVIEW metamodel forautomated analysis In International Conference on Com-putational Science and Computational Intelligence (p 1127-1132)

Quillereacute F Rajopadhye S amp Wilde D (2000) Generation of

efficient nested loops from polyhedra International Journalof Parallel Programming 28(5) 469ndash498

Robbes R Kamei Y amp Pinzger M (2017) Guest EditorialMining software repositories Empirical Software Engineer-ing 22(3) 1143ndash1145

Roberts D Opdyke W Beck K Fowler M amp Brant J(1999) Refactoring Improving the Design of Existing CodeAddison-Wesley Longman Publishing Boston

Services E (nd) Companies using labview httpsenlyftcomtechproductslabview (Accessed January 2020)

Stephan M amp Cordy J R (2015) Identification of Simulinkmodel antipattern instances using model clone detection In18th ACMIEEE International Conference on Model DrivenEngineering Languages and Systems (pp 276ndash285)

Tahmid A Nahar N amp Sakib K (2016) Understanding theevolution of code smells by observing code smell clusters In23rd IEEE International Conference on Software AnalysisEvolution and Reengineering (Vol 4 pp 8ndash11)

Thomas G Norman H Christian D amp Stefan K (2016)Artshop A continuous integration and quality assessmentframework for model-based software artifacts In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 13ndash22)

Toulmeacute A amp Inc I (2006) Presentation of EMF Compareutility In Eclipse Modeling Symposium (pp 1ndash8)

Tran Q M amp Dziobek C (2013) Approach to constructingand maintaining Simulink models based on the use of trans-formationrefactoring and generation operations In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 1ndash12)

Tufano M Palomba F Bavota G Oliveto R Di Penta MDe Lucia A amp Poshyvanyk D (2015) When and why yourcode starts to smell bad In 37th ACMIEEE InternationalConference on Software Engineering (Vol 1 pp 403ndash414)

Van Emden E amp Moonen L (2002) Java quality assuranceby detecting code smells In Proceedings of the 9th WorkingConference on Reverse Engineering (pp 97ndash106)

Zaman S Adams B amp Hassan A E (2012) A qualitativestudy on performance bugs In 9th IEEE Working Conferenceon Mining Software Repositories (pp 199ndash208)

Zhao X amp Gray J (2019) BESMER An approach for badsmells summarization in systems models In Models andEvolution Workshop at the 22nd ACMIEEE InternationalConference on Model Driven Engineering Languages andSystems (pp 304ndash313)

About the authorsSaheed Popoola is a PhD candidate in the Department of Com-puter Science at the University of Alabama His doctoral re-search deals with the evolution and design analysis of systemsmodels His broad research interests deals with the applicationof software engineering techniques to address software devel-opment challenges in systems engineering Prior to joiningthe University of Alabama he was a member of the Enter-prise Systems Group University of York where he obtainedan MSc (By Research) in Computer Science under the su-

14 Popoola et al

RepoDiffKind

AvgADD

AvgDELETE

AvgCHANGE

AvgMOVE

Repo 1 322 0 0 0

Repo 2 998 0 0 0

Repo 3 270 0 0 0

Repo 4 2288 15 122 106

Repo 5 4532 521 824 79

Repo 6 658 1 5 0

Repo 7 487 0 0 0

Repo 8 894 25 105 15

Repo 9 538 0 0 0

Repo 10 159 0 0 0

Table 3 Average Number of Difference Types Across VersionHistory

while three-way differencing involves the comparison of twomodels based on their evolution via a third common modelFor this study we used the two-way differencing for directcomparison between models in a specific version and models inthe succeeding version EMFCompare supports four types ofchanges between two sets of models ADD to indicate additionof new elements DELETE to show removal of existing elementsCHANGE to indicate the change of attribute values and MOVEto indicate reordering of elements

To analyse the differences in models across various versionseach version of the models in the identified repository was ex-tracted converted to an XMI format and then compared with itssucceeding version using EMFCompare for efficient extractionof changes between the versions These sets of changes werethen aggregated and analysed for all versions in a repositoryThis analysis makes it easy to understand the changes that ne-cessitate the evolution of LabVIEW programs These structuralchanges to the models were then mapped to the changes in thebad smells exhibited by such models

The results of the analysis of changes across the versionhistory of LabVIEW models in the 10 repositories show thatthe majority of the changes involved addition of new elementsTable 3 shows the average number of modifications that areperformed across each version in the repositories

The addition of new elements to succeeding versions alsocorresponds to increasing instances of smells in the repositoryFurthermore versions with a lower number of smell instancesare also associated with a higher number of deletions and at-tribute changes than number of additions Figure 12 shows thetrend of different kinds of changes in repository 2 It should benoted that there was a sharp increase in the number of deletionsand re-orderings (move) of elements There was also a decrease

Figure 12 Evolution of Change Kinds in Repository 2

in the number of additions This corresponds to the decrease inbad smells shown in Figures 6 to 9

8 Threats to ValidityThis paper presents an analysis of bad smells in LabVIEW mod-els Although a number of steps have been taken to ensure thatthe results presented in this paper are valid and generalizablewe have identified at least four main threats to the validity ofthe results presented in this paper

A Small sample size The sample size of the models used inthis evaluation is rather small and thus the results may notbe generalizable to all LabVIEW models The small sam-ple size is due to the relative young age of the LabVIEWNXG platform and the limited number of open-sourcerepositories that contain LAbVIEW NXG models

B Author demographics We do not know the experienceof the engineers who published the selected projects andhow their experience affected the quality of the selectedmodels It is possible that more experienced developersare able to produce models with higher quality and fewerinstances of bad smells Unfortunately information aboutthe author demographics could not be extracted from theGitHub repositories used in this study

C LabVIEW-specific smells and models The paper only con-siders LabVIEW models for the evaluation and some ofthe smells are specific to the LabVIEW environment Fur-thermore even though some of the smells are applicable toother systems modelling or data acquisition platforms thispaper only considers the effect of the smells on LabVIEWmodels Hence the results may not be generalizable for allsystems modeling or data acquisition environments

D Correctness of the queries The results presented in thispaper depend on the correctness of the queries used toidentify instances of bad smells in the LabVIEW modelsAlthough we have ensured that the queries in this paperare correct it may be possible that a new query generatessome false negatives or false positives

12 Popoola et al

We plan to address each of these concerns as part of futurework However we believe that the results reported in thispaper provide significant insight into the general evolution ofbad smells in systems models

9 Related WorkMuch work exists on bad smell identification in text-based lan-guages Chatzigeorgiou et al (Chatzigeorgiou amp Manakos2014) investigated the presence and persistence of bad smellsin two open source projects Their results show that bad smellsare introduced at the initial version and often persist up to thecurrent version of a project Furthermore the few eliminatedsmells often occur from a side effect of routine maintenanceactivities instead of a refactoring activity that specifically targetsthe removal of the smell Olbrich et al (Olbrich et al 2009)also conducted a similar study and concluded that code withsmells are more prone to frequent changes than projects that donot contain bad smells Tahmid et al (Tahmid et al 2016) alsopresented an approach for analysing bad smells in code reposi-tories based on the relationships between different bad smellsand the architecture of the source code The approach simplifiesthe development of clusters of bad smells embedded in the codefor easy refactoring However all of these approaches focuson text-based languages and none of them considered systemsmodels developed via graphical languages

Some work has been done to identify bad smells in graphicallanguages Simulink provides an interactive graphical envi-ronment for modeling simulating and analysing of dynamicsystems It includes a comprehensive library of predefinedblocks to be used to construct graphical models of systems us-ing drag-and-drop mouse operations Bad smells in Simulinksystems models are identified by Gerlitz et al (Gerlitz et al2015) In this work the authors summarized 21 bad smellsinto 5 categories name partition interface signal flow andsignal structure Two tools Artshopr (Thomas et al 2016) andSLRefactor (Tran amp Dziobek 2013) were implemented to ad-dress these bad smells Stephan and Cordy adopted near-misscross-clone detection to find instances of antipatterns derivedfrom the literature in public Simulink projects (Stephan amp Cordy2015)

Chambers and Scaffidi (Chambers amp Scaffidi 2013) devel-oped an approach for identifying bad smells in systems modelsvia interviews with modeling experts In our own earlier workwe developed an approach for identifying bad smells in Lab-VIEW models from an end-usersrsquo perspective by mining onlineforum posts (Zhao amp Gray 2019) However both (Chambersamp Scaffidi 2013) and (Zhao amp Gray 2019) do not investigatethe presence of the identified smells in code repositories nor dothey study the evolution of such smells This paper extends theliterature by proposing techniques for identifying bad smells ingraphical languages and analysing the evolution of such smellsacross the version history of the software systems developed

10 Conclusion and Future WorkWe introduced a semi-automated approach for detecting andanalysing bad smells in LabVIEW models via user-defined

queries The support for inheritance relationships in the Lab-VIEW metamodel was exploited to simplify the development ofuser queries to detect known bad smells from systems modelsThe approach has been evaluated on 69 models in 10 GitHubrepositories The evaluation process includes the analysis offour selected bad smells reported by end users The prelimi-nary results suggest that most smells are introduced in the earlyversions of a model and these smells often persist throughoutthe life cycle of the modeled system Furthermore most of theprojects contain three or four types of smells This may be anindication of the need for more automated analysis and refactor-ing support for systems engineers who may not be familiar withbad smell identification and refactoring

In the future we plan to carry out an extensive analysis onmore GitHub projects and other graphical modeling tools suchas Simulink The majority of the smells discussed in this paperare specific to LabVIEW hence we plan to cover more smellssuch as ldquoDuplicate Modelrdquo that can be generalizable to othergraphical modelling environments We also plan to conductqualitative studies that will complement the results presented inthis paper We will conduct studies to understand the contextin which bad smells are introduced the relationship betweenauthor demographics and bad smells and the level of consid-eration given to bad smells by LabVIEW developers Further-more we will implement and study the benefits of a refactoringmechanism to address the challenges of bad smells from theperspective of a systems engineer Finally we plan to improveour study to identify refactoring activities that specifically targetthe reduction of bad smells discover the impacts of bad smellson maintenance activities and highlight the differences in theanalysis of bad smells in graphical and textual languages

Acknowledgements

The authors would like to appreciate the contribution of DrTaylor Richeacute (National Instruments) and Dr Antonio Garcia-Dominguez (Aston University UK) for their help with generalquestions for LabVIEW and Hawk respectively We wouldalso like to thank the editors and reviewers for their time andinsightful feedback

References

Barmpis K Garciacutea-Domiacutenguez A Bagnato A amp AbherveA (2020) Monitoring model analytics over large repositorieswith hawk and measure In Model Management and Analyticsfor Large Scale Systems (pp 87ndash123) Elsevier

Barmpis K amp Kolovos D S (2014) Towards scalablequerying of large-scale models In 10th European Conferenceon Modelling Foundations and Applications (pp 35ndash50)

Bartelt C (2008) Consistence preserving model merge incollaborative development processes In Proceedings of theInternational Workshop on Comparison and Versioning ofSoftware Models (pp 13ndash18)

Carccedilao T (2014) Measuring and visualizing energy consump-tion within software code In IEEE Symposium on VisualLanguages and Human-Centric Computing (pp 181ndash182)

Evolution of Bad Smells in LabVIEW Graphical Models 13

Carccedilao T Cunha J Fernandes J P Pereira R amp Saraiva J(2014) Energy consumption detection in LabVIEW In IEEESymposium on Visual Languages and Human-Centric Com-puting Travel Support Competition httpwww4diuminhopt~jasResearchPapersnationalInstrumentspdf

Chambers C amp Scaffidi C (2013) Smell-driven performanceanalysis for end-user programmers In IEEE Symposiumon Visual Languages and Human Centric Computing (pp159ndash166)

Chatzigeorgiou A amp Manakos A (2014) Investigating theevolution of code smells in object-oriented systems Innova-tions in Systems and Software Engineering 10(1) 3ndash18

Exman I (2014) Linear software models standard modu-larity highlights residual coupling International Journal ofSoftware Engineering and Knowledge Engineering 24(02)183ndash210

Falcon J (2017) Facilitating modeling and simulation of com-plex systems through interoperable software In Keynote ad-dress at 20th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems

Gamma E Helm R Johnson R amp Vlissides J (1995) De-sign patterns Elements of reusable object-oriented softwareUSA Addison-Wesley Longman Publishing Co Inc

Garciacutea-Domiacutenguez A Bencomo N Parra-Ullauri J M ampGarciacutea-Paucar L H (2019) Querying and annotating modelhistories with time-aware patterns In 22nd ACMIEEE In-ternational Conference on Model Driven Engineering Lan-guages and Systems (pp 194ndash204)

Gerlitz T Tran Q M amp Dziobek C (2015) Detection andhandling of model smells for MATLABSimulink modelsIn Modeling in Automotive Software Engineering Workshopat the 18th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems (pp 13ndash22)

Johnson G W (1997) LabVIEW Graphical ProgrammingTata McGraw-Hill Education

Karunaratne M Tan C Kulkarni A Mitra T amp Peh L-S(2018) Dnestmap mapping deeply-nested loops on ultra-low power cgras In Proceedings of the 55th Annual DesignAutomation Conference (pp 1ndash6)

Loacutepez-Fernaacutendez J J Cuadrado J S Guerra E amp De Lara J(2015) Example-driven meta-model development Softwareand Systems Modeling 14(4) 1323ndash1347

Ludewig J (2003) Models in software engineeringndashAn intro-duction Software and Systems Modeling 2(1) 5ndash14

Olbrich S Cruzes D S Basili V amp Zazworka N (2009)The evolution and impact of code smells A case study oftwo open source systems In 3rd International Symposiumon Empirical Software Engineering and Measurement (pp390ndash400)

Opdyke W F (1992) Refactoring object-oriented frameworks(Unpublished doctoral dissertation) University of Illinois atUrbana-Champaign Champaign IL USA

Popoola S amp Gray J (2019) A LabVIEW metamodel forautomated analysis In International Conference on Com-putational Science and Computational Intelligence (p 1127-1132)

Quillereacute F Rajopadhye S amp Wilde D (2000) Generation of

efficient nested loops from polyhedra International Journalof Parallel Programming 28(5) 469ndash498

Robbes R Kamei Y amp Pinzger M (2017) Guest EditorialMining software repositories Empirical Software Engineer-ing 22(3) 1143ndash1145

Roberts D Opdyke W Beck K Fowler M amp Brant J(1999) Refactoring Improving the Design of Existing CodeAddison-Wesley Longman Publishing Boston

Services E (nd) Companies using labview httpsenlyftcomtechproductslabview (Accessed January 2020)

Stephan M amp Cordy J R (2015) Identification of Simulinkmodel antipattern instances using model clone detection In18th ACMIEEE International Conference on Model DrivenEngineering Languages and Systems (pp 276ndash285)

Tahmid A Nahar N amp Sakib K (2016) Understanding theevolution of code smells by observing code smell clusters In23rd IEEE International Conference on Software AnalysisEvolution and Reengineering (Vol 4 pp 8ndash11)

Thomas G Norman H Christian D amp Stefan K (2016)Artshop A continuous integration and quality assessmentframework for model-based software artifacts In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 13ndash22)

Toulmeacute A amp Inc I (2006) Presentation of EMF Compareutility In Eclipse Modeling Symposium (pp 1ndash8)

Tran Q M amp Dziobek C (2013) Approach to constructingand maintaining Simulink models based on the use of trans-formationrefactoring and generation operations In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 1ndash12)

Tufano M Palomba F Bavota G Oliveto R Di Penta MDe Lucia A amp Poshyvanyk D (2015) When and why yourcode starts to smell bad In 37th ACMIEEE InternationalConference on Software Engineering (Vol 1 pp 403ndash414)

Van Emden E amp Moonen L (2002) Java quality assuranceby detecting code smells In Proceedings of the 9th WorkingConference on Reverse Engineering (pp 97ndash106)

Zaman S Adams B amp Hassan A E (2012) A qualitativestudy on performance bugs In 9th IEEE Working Conferenceon Mining Software Repositories (pp 199ndash208)

Zhao X amp Gray J (2019) BESMER An approach for badsmells summarization in systems models In Models andEvolution Workshop at the 22nd ACMIEEE InternationalConference on Model Driven Engineering Languages andSystems (pp 304ndash313)

About the authorsSaheed Popoola is a PhD candidate in the Department of Com-puter Science at the University of Alabama His doctoral re-search deals with the evolution and design analysis of systemsmodels His broad research interests deals with the applicationof software engineering techniques to address software devel-opment challenges in systems engineering Prior to joiningthe University of Alabama he was a member of the Enter-prise Systems Group University of York where he obtainedan MSc (By Research) in Computer Science under the su-

14 Popoola et al

We plan to address each of these concerns as part of futurework However we believe that the results reported in thispaper provide significant insight into the general evolution ofbad smells in systems models

9 Related WorkMuch work exists on bad smell identification in text-based lan-guages Chatzigeorgiou et al (Chatzigeorgiou amp Manakos2014) investigated the presence and persistence of bad smellsin two open source projects Their results show that bad smellsare introduced at the initial version and often persist up to thecurrent version of a project Furthermore the few eliminatedsmells often occur from a side effect of routine maintenanceactivities instead of a refactoring activity that specifically targetsthe removal of the smell Olbrich et al (Olbrich et al 2009)also conducted a similar study and concluded that code withsmells are more prone to frequent changes than projects that donot contain bad smells Tahmid et al (Tahmid et al 2016) alsopresented an approach for analysing bad smells in code reposi-tories based on the relationships between different bad smellsand the architecture of the source code The approach simplifiesthe development of clusters of bad smells embedded in the codefor easy refactoring However all of these approaches focuson text-based languages and none of them considered systemsmodels developed via graphical languages

Some work has been done to identify bad smells in graphicallanguages Simulink provides an interactive graphical envi-ronment for modeling simulating and analysing of dynamicsystems It includes a comprehensive library of predefinedblocks to be used to construct graphical models of systems us-ing drag-and-drop mouse operations Bad smells in Simulinksystems models are identified by Gerlitz et al (Gerlitz et al2015) In this work the authors summarized 21 bad smellsinto 5 categories name partition interface signal flow andsignal structure Two tools Artshopr (Thomas et al 2016) andSLRefactor (Tran amp Dziobek 2013) were implemented to ad-dress these bad smells Stephan and Cordy adopted near-misscross-clone detection to find instances of antipatterns derivedfrom the literature in public Simulink projects (Stephan amp Cordy2015)

Chambers and Scaffidi (Chambers amp Scaffidi 2013) devel-oped an approach for identifying bad smells in systems modelsvia interviews with modeling experts In our own earlier workwe developed an approach for identifying bad smells in Lab-VIEW models from an end-usersrsquo perspective by mining onlineforum posts (Zhao amp Gray 2019) However both (Chambersamp Scaffidi 2013) and (Zhao amp Gray 2019) do not investigatethe presence of the identified smells in code repositories nor dothey study the evolution of such smells This paper extends theliterature by proposing techniques for identifying bad smells ingraphical languages and analysing the evolution of such smellsacross the version history of the software systems developed

10 Conclusion and Future WorkWe introduced a semi-automated approach for detecting andanalysing bad smells in LabVIEW models via user-defined

queries The support for inheritance relationships in the Lab-VIEW metamodel was exploited to simplify the development ofuser queries to detect known bad smells from systems modelsThe approach has been evaluated on 69 models in 10 GitHubrepositories The evaluation process includes the analysis offour selected bad smells reported by end users The prelimi-nary results suggest that most smells are introduced in the earlyversions of a model and these smells often persist throughoutthe life cycle of the modeled system Furthermore most of theprojects contain three or four types of smells This may be anindication of the need for more automated analysis and refactor-ing support for systems engineers who may not be familiar withbad smell identification and refactoring

In the future we plan to carry out an extensive analysis onmore GitHub projects and other graphical modeling tools suchas Simulink The majority of the smells discussed in this paperare specific to LabVIEW hence we plan to cover more smellssuch as ldquoDuplicate Modelrdquo that can be generalizable to othergraphical modelling environments We also plan to conductqualitative studies that will complement the results presented inthis paper We will conduct studies to understand the contextin which bad smells are introduced the relationship betweenauthor demographics and bad smells and the level of consid-eration given to bad smells by LabVIEW developers Further-more we will implement and study the benefits of a refactoringmechanism to address the challenges of bad smells from theperspective of a systems engineer Finally we plan to improveour study to identify refactoring activities that specifically targetthe reduction of bad smells discover the impacts of bad smellson maintenance activities and highlight the differences in theanalysis of bad smells in graphical and textual languages

Acknowledgements

The authors would like to appreciate the contribution of DrTaylor Richeacute (National Instruments) and Dr Antonio Garcia-Dominguez (Aston University UK) for their help with generalquestions for LabVIEW and Hawk respectively We wouldalso like to thank the editors and reviewers for their time andinsightful feedback

References

Barmpis K Garciacutea-Domiacutenguez A Bagnato A amp AbherveA (2020) Monitoring model analytics over large repositorieswith hawk and measure In Model Management and Analyticsfor Large Scale Systems (pp 87ndash123) Elsevier

Barmpis K amp Kolovos D S (2014) Towards scalablequerying of large-scale models In 10th European Conferenceon Modelling Foundations and Applications (pp 35ndash50)

Bartelt C (2008) Consistence preserving model merge incollaborative development processes In Proceedings of theInternational Workshop on Comparison and Versioning ofSoftware Models (pp 13ndash18)

Carccedilao T (2014) Measuring and visualizing energy consump-tion within software code In IEEE Symposium on VisualLanguages and Human-Centric Computing (pp 181ndash182)

Evolution of Bad Smells in LabVIEW Graphical Models 13

Carccedilao T Cunha J Fernandes J P Pereira R amp Saraiva J(2014) Energy consumption detection in LabVIEW In IEEESymposium on Visual Languages and Human-Centric Com-puting Travel Support Competition httpwww4diuminhopt~jasResearchPapersnationalInstrumentspdf

Chambers C amp Scaffidi C (2013) Smell-driven performanceanalysis for end-user programmers In IEEE Symposiumon Visual Languages and Human Centric Computing (pp159ndash166)

Chatzigeorgiou A amp Manakos A (2014) Investigating theevolution of code smells in object-oriented systems Innova-tions in Systems and Software Engineering 10(1) 3ndash18

Exman I (2014) Linear software models standard modu-larity highlights residual coupling International Journal ofSoftware Engineering and Knowledge Engineering 24(02)183ndash210

Falcon J (2017) Facilitating modeling and simulation of com-plex systems through interoperable software In Keynote ad-dress at 20th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems

Gamma E Helm R Johnson R amp Vlissides J (1995) De-sign patterns Elements of reusable object-oriented softwareUSA Addison-Wesley Longman Publishing Co Inc

Garciacutea-Domiacutenguez A Bencomo N Parra-Ullauri J M ampGarciacutea-Paucar L H (2019) Querying and annotating modelhistories with time-aware patterns In 22nd ACMIEEE In-ternational Conference on Model Driven Engineering Lan-guages and Systems (pp 194ndash204)

Gerlitz T Tran Q M amp Dziobek C (2015) Detection andhandling of model smells for MATLABSimulink modelsIn Modeling in Automotive Software Engineering Workshopat the 18th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems (pp 13ndash22)

Johnson G W (1997) LabVIEW Graphical ProgrammingTata McGraw-Hill Education

Karunaratne M Tan C Kulkarni A Mitra T amp Peh L-S(2018) Dnestmap mapping deeply-nested loops on ultra-low power cgras In Proceedings of the 55th Annual DesignAutomation Conference (pp 1ndash6)

Loacutepez-Fernaacutendez J J Cuadrado J S Guerra E amp De Lara J(2015) Example-driven meta-model development Softwareand Systems Modeling 14(4) 1323ndash1347

Ludewig J (2003) Models in software engineeringndashAn intro-duction Software and Systems Modeling 2(1) 5ndash14

Olbrich S Cruzes D S Basili V amp Zazworka N (2009)The evolution and impact of code smells A case study oftwo open source systems In 3rd International Symposiumon Empirical Software Engineering and Measurement (pp390ndash400)

Opdyke W F (1992) Refactoring object-oriented frameworks(Unpublished doctoral dissertation) University of Illinois atUrbana-Champaign Champaign IL USA

Popoola S amp Gray J (2019) A LabVIEW metamodel forautomated analysis In International Conference on Com-putational Science and Computational Intelligence (p 1127-1132)

Quillereacute F Rajopadhye S amp Wilde D (2000) Generation of

efficient nested loops from polyhedra International Journalof Parallel Programming 28(5) 469ndash498

Robbes R Kamei Y amp Pinzger M (2017) Guest EditorialMining software repositories Empirical Software Engineer-ing 22(3) 1143ndash1145

Roberts D Opdyke W Beck K Fowler M amp Brant J(1999) Refactoring Improving the Design of Existing CodeAddison-Wesley Longman Publishing Boston

Services E (nd) Companies using labview httpsenlyftcomtechproductslabview (Accessed January 2020)

Stephan M amp Cordy J R (2015) Identification of Simulinkmodel antipattern instances using model clone detection In18th ACMIEEE International Conference on Model DrivenEngineering Languages and Systems (pp 276ndash285)

Tahmid A Nahar N amp Sakib K (2016) Understanding theevolution of code smells by observing code smell clusters In23rd IEEE International Conference on Software AnalysisEvolution and Reengineering (Vol 4 pp 8ndash11)

Thomas G Norman H Christian D amp Stefan K (2016)Artshop A continuous integration and quality assessmentframework for model-based software artifacts In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 13ndash22)

Toulmeacute A amp Inc I (2006) Presentation of EMF Compareutility In Eclipse Modeling Symposium (pp 1ndash8)

Tran Q M amp Dziobek C (2013) Approach to constructingand maintaining Simulink models based on the use of trans-formationrefactoring and generation operations In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 1ndash12)

Tufano M Palomba F Bavota G Oliveto R Di Penta MDe Lucia A amp Poshyvanyk D (2015) When and why yourcode starts to smell bad In 37th ACMIEEE InternationalConference on Software Engineering (Vol 1 pp 403ndash414)

Van Emden E amp Moonen L (2002) Java quality assuranceby detecting code smells In Proceedings of the 9th WorkingConference on Reverse Engineering (pp 97ndash106)

Zaman S Adams B amp Hassan A E (2012) A qualitativestudy on performance bugs In 9th IEEE Working Conferenceon Mining Software Repositories (pp 199ndash208)

Zhao X amp Gray J (2019) BESMER An approach for badsmells summarization in systems models In Models andEvolution Workshop at the 22nd ACMIEEE InternationalConference on Model Driven Engineering Languages andSystems (pp 304ndash313)

About the authorsSaheed Popoola is a PhD candidate in the Department of Com-puter Science at the University of Alabama His doctoral re-search deals with the evolution and design analysis of systemsmodels His broad research interests deals with the applicationof software engineering techniques to address software devel-opment challenges in systems engineering Prior to joiningthe University of Alabama he was a member of the Enter-prise Systems Group University of York where he obtainedan MSc (By Research) in Computer Science under the su-

14 Popoola et al

Carccedilao T Cunha J Fernandes J P Pereira R amp Saraiva J(2014) Energy consumption detection in LabVIEW In IEEESymposium on Visual Languages and Human-Centric Com-puting Travel Support Competition httpwww4diuminhopt~jasResearchPapersnationalInstrumentspdf

Chambers C amp Scaffidi C (2013) Smell-driven performanceanalysis for end-user programmers In IEEE Symposiumon Visual Languages and Human Centric Computing (pp159ndash166)

Chatzigeorgiou A amp Manakos A (2014) Investigating theevolution of code smells in object-oriented systems Innova-tions in Systems and Software Engineering 10(1) 3ndash18

Exman I (2014) Linear software models standard modu-larity highlights residual coupling International Journal ofSoftware Engineering and Knowledge Engineering 24(02)183ndash210

Falcon J (2017) Facilitating modeling and simulation of com-plex systems through interoperable software In Keynote ad-dress at 20th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems

Gamma E Helm R Johnson R amp Vlissides J (1995) De-sign patterns Elements of reusable object-oriented softwareUSA Addison-Wesley Longman Publishing Co Inc

Garciacutea-Domiacutenguez A Bencomo N Parra-Ullauri J M ampGarciacutea-Paucar L H (2019) Querying and annotating modelhistories with time-aware patterns In 22nd ACMIEEE In-ternational Conference on Model Driven Engineering Lan-guages and Systems (pp 194ndash204)

Gerlitz T Tran Q M amp Dziobek C (2015) Detection andhandling of model smells for MATLABSimulink modelsIn Modeling in Automotive Software Engineering Workshopat the 18th ACMIEEE International Conference on ModelDriven Engineering Languages and Systems (pp 13ndash22)

Johnson G W (1997) LabVIEW Graphical ProgrammingTata McGraw-Hill Education

Karunaratne M Tan C Kulkarni A Mitra T amp Peh L-S(2018) Dnestmap mapping deeply-nested loops on ultra-low power cgras In Proceedings of the 55th Annual DesignAutomation Conference (pp 1ndash6)

Loacutepez-Fernaacutendez J J Cuadrado J S Guerra E amp De Lara J(2015) Example-driven meta-model development Softwareand Systems Modeling 14(4) 1323ndash1347

Ludewig J (2003) Models in software engineeringndashAn intro-duction Software and Systems Modeling 2(1) 5ndash14

Olbrich S Cruzes D S Basili V amp Zazworka N (2009)The evolution and impact of code smells A case study oftwo open source systems In 3rd International Symposiumon Empirical Software Engineering and Measurement (pp390ndash400)

Opdyke W F (1992) Refactoring object-oriented frameworks(Unpublished doctoral dissertation) University of Illinois atUrbana-Champaign Champaign IL USA

Popoola S amp Gray J (2019) A LabVIEW metamodel forautomated analysis In International Conference on Com-putational Science and Computational Intelligence (p 1127-1132)

Quillereacute F Rajopadhye S amp Wilde D (2000) Generation of

efficient nested loops from polyhedra International Journalof Parallel Programming 28(5) 469ndash498

Robbes R Kamei Y amp Pinzger M (2017) Guest EditorialMining software repositories Empirical Software Engineer-ing 22(3) 1143ndash1145

Roberts D Opdyke W Beck K Fowler M amp Brant J(1999) Refactoring Improving the Design of Existing CodeAddison-Wesley Longman Publishing Boston

Services E (nd) Companies using labview httpsenlyftcomtechproductslabview (Accessed January 2020)

Stephan M amp Cordy J R (2015) Identification of Simulinkmodel antipattern instances using model clone detection In18th ACMIEEE International Conference on Model DrivenEngineering Languages and Systems (pp 276ndash285)

Tahmid A Nahar N amp Sakib K (2016) Understanding theevolution of code smells by observing code smell clusters In23rd IEEE International Conference on Software AnalysisEvolution and Reengineering (Vol 4 pp 8ndash11)

Thomas G Norman H Christian D amp Stefan K (2016)Artshop A continuous integration and quality assessmentframework for model-based software artifacts In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 13ndash22)

Toulmeacute A amp Inc I (2006) Presentation of EMF Compareutility In Eclipse Modeling Symposium (pp 1ndash8)

Tran Q M amp Dziobek C (2013) Approach to constructingand maintaining Simulink models based on the use of trans-formationrefactoring and generation operations In DagstuhlWorkshops ndash Model Based Engineering of Embedded Systems(pp 1ndash12)

Tufano M Palomba F Bavota G Oliveto R Di Penta MDe Lucia A amp Poshyvanyk D (2015) When and why yourcode starts to smell bad In 37th ACMIEEE InternationalConference on Software Engineering (Vol 1 pp 403ndash414)

Van Emden E amp Moonen L (2002) Java quality assuranceby detecting code smells In Proceedings of the 9th WorkingConference on Reverse Engineering (pp 97ndash106)

Zaman S Adams B amp Hassan A E (2012) A qualitativestudy on performance bugs In 9th IEEE Working Conferenceon Mining Software Repositories (pp 199ndash208)

Zhao X amp Gray J (2019) BESMER An approach for badsmells summarization in systems models In Models andEvolution Workshop at the 22nd ACMIEEE InternationalConference on Model Driven Engineering Languages andSystems (pp 304ndash313)

About the authorsSaheed Popoola is a PhD candidate in the Department of Com-puter Science at the University of Alabama His doctoral re-search deals with the evolution and design analysis of systemsmodels His broad research interests deals with the applicationof software engineering techniques to address software devel-opment challenges in systems engineering Prior to joiningthe University of Alabama he was a member of the Enter-prise Systems Group University of York where he obtainedan MSc (By Research) in Computer Science under the su-

14 Popoola et al

pervision of Prof Dimitris Kolovos You can contact him atsopopoolacrimsonuaedu or visit httppopoolacsuaedu

Xin Zhao is a PhD candidate in the Department of ComputerScience at the University of Alabama His doctoral researchinvestigates the evaluation of systems models including badsmells categorization model refactoring and metrics analyses ofsystems models He is also interested in software product linesand CS education He obtained his BE in the Hebei NormalUniversity China Before joining the University of Alabamahe was a member of the National Engineering Research Centerfor Multimedia Software Wuhan University China You cancontact him at xzhao24crimsonuaedu or visit httpxzhao24studentscsuaedu

Jeff Gray is a Professor in the Department of Computer Scienceat the University of Alabama His research interests are in theareas of software engineering model-driven engineering andcomputer science education Jeff is a Distinguished Member ofthe ACM and a Senior Member of the IEEE He is the co-Editorin Chief of the Journal of Software and Systems Modeling(SoSyM) You can contact him at graycsuaedu or visit httpgraycsuaedu

Evolution of Bad Smells in LabVIEW Graphical Models 15