Fixing Design Inconsistencies of Polymorphic Methods Using

e-Informatica Software Engineering Journal, Volume 15, Issue 1, 2021, pages: 7–27, DOI 10.37190/e-Inf210101

Fixing Design Inconsistencies of PolymorphicMethods Using Swarm Intelligence

Renu George∗, Philip Samuel∗∗Department of Computer Science, Cochin University of Science and Technology

[email protected], [email protected]://orcid.org/0000-0002-3276-2961

AbstractBackground: Modern industry is heavily dependent on software. The complexity of designingand developing software is a serious engineering issue. With the growing size of software systemsand increase in complexity, inconsistencies arise in software design and intelligent techniques arerequired to detect and fix inconsistencies.Aim: Current industrial practice of manually detecting inconsistencies is time consuming, errorprone and incomplete. Inconsistencies arising as a result of polymorphic object interactions arehard to trace. We propose an approach to detect and fix inconsistencies in polymorphic methodinvocations in sequence models.Method: A novel intelligent approach based on self regulating particle swarm optimization to solvethe inconsistency during software system design is presented. Inconsistency handling is modelledas an optimization problem that uses a maximizing fitness function. The proposed approach alsoidentifies the changes required in the design diagrams to fix the inconsistencies.Result: The method is evaluated on different software design models involving static and dynamicpolymorphism and inconsistencies are detected and resolved.Conclusion: Ensuring consistency of design is highly essential to develop quality software andsolves a major design issue for practitioners. In addition, our approach helps to reduce the timeand cost of developing software.

Keywords: UML models, software design inconsistency, polymorphism, particle swarmoptimization

1. Introduction

Today′s biggest industry is software industry interms of manpower, complex interactions andchanging tasks with evolving designs. The waypeople coordinate activities and work has seena major transformation since the use of softwarein industries. With the increasing relevance ofsoftware in industries, software development hasbecome more complex. Software changes are fre-quent due to evolution, agility and adaptability.Customized software is used to increase produc-tivity in industries and quality of the softwareis a prime concern. Design and development ofquality software is a major challenge for software

developers and many a times, the process is man-ual. Artificial intelligence (AI) techniques canreplace many of these manual efforts to make thedevelopment of software easier and cost effective.

Artificial intelligence replicates human deci-sion making techniques to make machines moreintelligent. Software development involves sev-eral complex human decision makings that dealwith the task of designing, implementing anddeploying complex systems. Software engineer-ing problems can be represented as optimizationproblems. Search based software systems use op-timization techniques and computational searchtechniques to solve problems in software engineer-ing [1]. Although search based systems address

Submitted: 08 April 2020; Revised: 02 November 2020; Accepted: 14 December 2020; Available online: 02 February 2021

http://www.e-informatyka.pl/wiki/e-Informatica

http://www.e-informatyka.pl/attach/e-Informatica_-_Volume_15/eInformatica2021Art01.pdf

8 Renu George, Philip Samuel

many problems in software requirements anddesign, design verification is not yet addressed[2, 3]. Particle swarm optimization (PSO) is anoptimization technique based on population withcomputational intelligence [4]. Self RegulatingParticle Swarm Optimization (SRPSO) is an im-proved version of PSO that provides optimumsolutions by incorporating the best strategiesfor human learning [5]. We present an intelli-gent approach based on SRPSO to solve theinconsistency in polymorphic methods duringthe software system design.

The modelling language widely used for re-quirements modelling and documentation of thesystem is Unified Modeling Language (UML).UML models handle the complexity of the sys-tem by expressing different views with differentdiagrams that consist of a number of interre-lated model elements. The interrelated designdiagrams contain redundant information in theoverlapping model elements. Hence, the proba-bility of occurrence of design inconsistencies ismore. The diagrams of a single system repre-senting the static and dynamic aspects shouldbe consistent and not contradictory [6]. Explicitmechanisms are required to verify the consistencyof redundant information present across the dia-grams [7, 8]. Generally, models are constructedfor a specific application and the models are even-tually implemented, usually in an object orientedprogramming language. Validating the modelsfor consistency in the design phase guaranteethat the design inconsistencies are not carriedover to the code generation phase of softwaredevelopment. Automated consistency checkingduring the design phase ensures software quality,reduced development and maintenance cost andless time to market. Inconsistent design resultsin incorrect code, design rework, failure to meettimelines, and increase in cost of production.

Polymorphism is one of the key concepts thatdetermine the quality of object oriented softwaresystems [9]. Polymorphism enables different be-havior to be associated with a method name. Newmethods with different implementation can becreated with the same interface and the amountof work required to handle and distinguish differ-ent objects is reduced [9]. The result of execution

of a polymorphic method depends on the objectthat executes the method and produces differ-ent results when received by different objects.The advantages of designing multiple methodswith the same name make polymorphism an effi-cient approach during software design. We definean inconsistency related to object interactionsin polymorphic and non-polymorphic methods:method-invocation inconsistency. Inconsistencyexists if the method invocations are bound toa wrong class in the sequence diagram, i.e., themethod is not invoked on an object of the classin which the method is defined. Inconsistenciesin polymorphic method invocations cannot beidentified by validating the method names asall polymorphic methods have the same name.Hence, detection of method invocation incon-sistency in polymorphic methods requires moreeffort than non-polymorphic methods. As thedesign complexity increases, manual verificationof inconsistencies in polymorphic methods is notpractical. Intelligent techniques that require ex-pertise are required to detect and solve the in-consistencies.

Method-invocation inconsistency occurs whena polymorphic or non-polymorphic method is in-voked on a wrong object in the sequence diagram.The existing approaches of detecting inconsisten-cies in method invocations specified in [10–15]do not mention inconsistencies in polymorphicmethods. Although polymorphism has a numberof advantages, serious flaws may occur due toinconsistencies. Programmers may find it a chal-lenging task to understand all the interactionsbetween sender and receiver objects [16]. Under-standing polymorphic codes is hard and there-fore, fault-prone. Usually inconsistencies relatedto polymorphic method invocations are difficultto identify during testing phase. Separate tests arerequired for each polymorphic method binding.Identifying and testing all possible bindings ofcertain polymorphic references is difficult therebyincreasing the chances of errors [17]. Inconsistentpolymorphic behaviours may cause huge financialproblems when detected.

Software design is prone to errors and designimperfections have a significant effect on softwarequality. Software failure can be attributed to var-

Fixing Design Inconsistencies of Polymorphic Methods Using Swarm Intelligence 9

ious factors starting from requirements gatheringto testing and poor quality management [18]. In-consistencies in the design lead to the generationof defective software. One of the major activi-ties in ensuring quality involves detection andremoval of defects in the design. As the errors arecarried over from the software design phase to thedevelopment phase, the cost incurred in fixingthe error also increases. Defect detection duringthe design phase significantly prevents propaga-tion of errors to further stages of software devel-opment and reduces development cost [19, 20].Hence, code generation is based on consistentdesigns. This facilitates generation of softwarewith fewer faults and improves the quality ofthe software generated. Development of softwarewith fewer faults reduces the maintenance costof the software. Cost increases with the delay indetecting and correcting the error. The cost of de-tecting defects after release is 30 times more thanthe cost of detecting defects in the analysis anddesign phase [19]. Therefore, inconsistency detec-tion in the software design phase is inevitable forthe development of accurate and quality software.We propose an intelligent approach to detectand fix inconsistencies during the design phaseof software development. Inconsistencies are de-tected and handled with a fitness function bygenerating fitness values for each polymorphicand non-polymorphic method in the class dia-gram and sequence diagram. Inconsistencies arehandled by maximizing the fitness values of meth-ods subject to the constraint that the methodsare invoked on the right classes. The proposedautomated intelligent approach for consistencychecking during the design phase facilitates gen-eration of software with fewer faults, improvessoftware quality, and reduces development andmaintenance cost.

The organization of the paper is as follows. Therelated works in the areas of consistency checkingand the various applications of PSO and its vari-ants is presented in Section 2. Section 3 deals withthe inconsistencies in polymorphic methods. Thearchitecture of the consistency checking system isdescribed in Section 4 and the implementation ofthe proposed approach is presented in Section 5.Results and discussion are presented in Section 6,

threats to validity is presented in Section 7 andSection 8 concludes the paper.

2. Related work

The section presents the consistency handlingtechniques available in the literature and theapplications of PSO techniques to find optimalsolutions in software development and industries.

Inconsistencies in the design may result inthe failure of a software project. The problemsof establishing and maintaining consistency isdiscussed in [21]. The authors state that it isimpossible to avoid inconsistency and more flexi-bility can be obtained by using tools that manageand tolerate inconsistency. A tool that detectsinconsistency and locates the choices for fixinginconsistency is proposed in [10]. Model profilingis used to determine the model elements affectedwhile evaluating a rule; a set of choices for fixingthe inconsistency is proposed and the designer de-cides the choice for fixing the inconsistency. Themethod proposed in [11] fixes inconsistencies inclass, sequence and statechart diagrams by gen-erating a set of concrete changes automatically.The work focuses on deciding a method to fixinconsistencies. An approach that performs realtime detection and tracking of inconsistenciesin class, sequence and state chart diagrams ispresented in [12]. Consistency checks are initiatedduring a model change.

The algorithm proposed in [13] performs con-sistency check on class and sequence diagramsbased on the syntax specified and generates a se-quence of Relational Calculus of Object Sys-tems (rCOS) class declarations. Inconsistenciesin well-formed class and sequence diagrams aredetected with an algorithm based on breadth firstsearch technique. Transformation, refactoring,merging or repair of models result in changes inthe model and during consistency checking it maylead to performance problems. An automatedapproach with tool support to re-validate partsof the design rule affected by model transforma-tion or repair is proposed in [22]. Although thepaper mentions inconsistency in sequence andclass diagrams, the focus is on improving the


performance of incremental consistency check-ing by identifying parts of the model affectedby model changes. A prototype tool developedusing a UML based approach to handle impactanalysis is proposed in [14]. Consistency checkis performed on the UML diagrams, differencebetween the two versions is identified and themodel elements that are directly or indirectlyaffected by the changes are determined. The fo-cus of the paper is on changes and its impact,i.e. which model elements are affected by thechange. Instant detection of consistency betweensource code and design models is performed in[23] and a live report of the consistency statusof the project is provided to the developers.

A classification of model repair techniquesbased on features is presented in [24]. The fo-cus is on proposing taxonomy for model repairtechniques and not on inconsistency detectionand causes of inconsistency. The paper [15] pro-poses a method for automatic generation of exe-cutable and concrete repairs for models based onthe inconsistency information, a set of generatorfunctions and abstract repairs. An automatedplanning approach based on artificial intelligenceis proposed in [25] to resolve inconsistencies. A re-gression planner is implemented in Prolog. Theapproach is restricted to detection of structuralinconsistencies in class diagrams only.

A review of the consistency management ap-proaches available in the literature is presentedin [26]. The works described does not addressinconsistencies related to polymorphic methods.Object Constraint Language (OCL) rules are spec-ified for consistency checking of UML model in[27], the approach does not address polymorphicmethods. Consistency rules to detect inconsis-tencies in method invocations between sequenceand class diagrams are presented in [28], but noapproaches are presented to detect and fix in-consistency. A method to detect inconsistenciesbetween state diagrams and communication dia-grams using the language Alloy is presented in [29].

Soft computing techniques find its applicationin providing solutions to problems in industries.PSO is used to minimize the cost of heating sys-tem [30], to assign applications to resources in thecloud [31], in job-shop scheduling [32], in network-

ing [33], power systems [34, 35], signal processing[36], control system [37] and many more. PSO isalso applied to find effective solutions to prob-lems in software development. PSO is applied toUML class diagram and an algorithm for classresponsibility assignment problem is presentedin [38]. The PSO method reassigns the attributesand methods to the different classes indicated inthe class diagram. The application of SRPSO andPSO in detecting and resolving inconsistencies inclass attribute definitions is presented in [39, 40].The fitness value determines the consistency ofattributes and the PSO and SRPSO algorithmiterates to fix inconsistency by optimizing thefitness value of attributes. The papers deal withfixing inconsistencies in attribute definitions only.The performance of SRPSO algorithm is betterthan PSO in term of statistical evaluation pa-rameters and convergence. An SRPSO basedapproach to fix state change inconsistencies instate diagrams and sequence diagrams is pro-posed in [41]. Inconsistencies are detected andfixed with a fitness function.

An optimization based approach using PSOand simulated annealing to find transformationfragments that best cover the source model isproposed in [42]. PSO is applied to achieve highstructural code coverage in evolutionary struc-tural testing by generating test cases automat-ically [43]. Parameter estimation using PSO topredict reliability of software reliability growthmodels (SRGM) is described in [44]. Duringtesting, faults are detected and a mathemati-cal model SRGM, models the properties of theprocess. A comparative study of metaheuristicoptimization framework is proposed in [45] andthe study states that a wider implementation ofsoftware engineering practices is required.

The application of PSO in diverse areas of en-gineering has yielded better results over existingmethods, but works that describe the applica-tion of PSO in the design phase for softwaredesign consistency checking is rare. Althoughconsistency checking of UML models is a widelydiscussed problem and different techniques todetect and fix inconsistencies are available in theliterature, techniques that perform consistencychecking of polymorphic methods are rarely re-


ported. We present an intelligent approach thatdetects inconsistencies with a fitness function.Inconsistencies are fixed by remodelling the se-quence diagram method invocations during iter-ations of the SRPSO algorithm. Our approachefficiently detects and fixes the inconsistencies.

3. Inconsistenciesin polymorphic methods

Polymorphism is an important feature of objectoriented programming that provides simplicityand flexibility to the design and code. It en-ables different behaviour to be associated witha method name. Polymorphism keeps the designsimple, flexible and extensible [46]. New meth-ods with different implementation can be createdwith the same interface and the amount of workrequired to handle and distinguish different ob-jects is reduced. Each polymorphic method hasa class specific way to respond to a message. Poly-morphic methods execute different subroutinesdepending on the type of object they are appliedto. Inconsistency occurs if the method is invokedon a wrong class. Two methods of implement-ing polymorphism are (a) static binding: meth-ods have the same name, different signature anddifferent implementation (b) dynamic dispatch:methods have the same name, same signatureand different implementation [47]. Static bindingoccurs with method overloading at compile timeand the method to be invoked is determined fromthe signature of the method call. Dynamic dis-patch is related to inheritance hierarchy. Methodoverriding provides a superclass/subclass inher-itance hierarchy allowing different subclass im-plementation of inherited methods [48, 49]. Theoverriding methods represent different function-alities and require different algorithms [50]. Theexact method to which the method call is boundis known only at run time. Method overriding isimplemented with dynamic dispatch [49].

Inconsistency in UML models occurs whentwo or more diagrams describe different aspectsof the system and they are not jointly satisfiable.Any method invoked on an object in the sequencediagram should be defined in the class instan-

tiated by the receiving object. The rule is partof the UML well-formedness principle. There isscope for many subtle errors with polymorphismsince a method name occurs in more than oneclass. The exact operation to be performed is de-termined from the data types of the argumentsin static polymorphism. The same signature isused by more than one class in dynamic poly-morphism and determining whether the correctmethod is invoked in the sequence diagram isan issue. Understanding polymorphic codes ishard and therefore fault-prone [16]. Hence, in-consistency detection during the design phasehas become inevitable for the development ofaccurate software [16]. We propose an intelligentapproach using SRPSO algorithm to detect andfix method-invocation inconsistency in polymor-phic methods. Method invocation inconsistencyis identified from the signatures of the class di-agram and sequence diagram methods in staticpolymorphism. The method signatures are thesame for all polymorphic methods in dynamicpolymorphism and hence more difficult. Incon-sistency is detected from the guard condition formessage invocation in the sequence diagram andprecondition for the method in the class diagram.

The inconsistencies are illustrated with theUML models 3DObject and ThreeDObject rep-resented in Figures 1 and 2, respectively. Theclass diagram and sequence diagram for the UMLmodel 3DObject is represented in Figure 1 . Themodel provides an example of static polymor-phism. The class diagram consists of 4 classes.A generalized class ThreeDShape is defined withan attribute Area of type float. The classesSphere, Cuboid and Cylinder are specializationsof the class ThreeDShape. The methods com-puteArea() and perimeter() defined in the classesSphere, Cuboid and Cylinder are polymorphicsince methods with the same name and differ-ent signature are defined. The method vertices()defined in the class Cuboid is non-polymorphic.The sequence diagram represents the method in-vocations to compute the area of the objects. Theclass Cuboid has a method computeArea(l, b, h)with signature computeArea(int, int, int). Sim-ilarly, the signatures of the method com-puteArea() defined in the classes Sphere


Figure 1. Class Diagram and Sequence Diagram for UML Model for 3DObject

Figure 2. Class Diagram and Sequence Diagram for UML Model for 3DObject

and Cylinder are computeArea(int) and com-puteArea(float, fint), respectively. The signaturesof the method computeArea() invoked on theobjects of classes Cuboid, Sphere and Cylinderin the sequence diagram are computeArea(int,int, int), computeArea(float, int) and com-puteArea(int). The invocations of the polymor-phic method computeArea(l, b, h) and thenon-polymorphic method vertices() are consis-tent whereas the invocations of the polymorphicmethods, computeArea(s) and computeArea(r, h)are inconsistent. The inconsistencies, if unnoticed

will result in a wrong value for area. Inconsisten-cies are detected by computing the fitness valuesof methods. The fitness value computation todetect inconsistency is represented in Table 1.

A UML model ThreeDObject representingdynamic polymorphism is depicted in Figure 2.A method computeArea() and two attributesArea and face are defined in the class Three-DObject. The method is overridden in the childclasses since the method of computing area de-pends on the shape of the object. The attributeface represents the number of faces possessed by

Table 1. Fitness values of methods in UML Models 3DObject and ThreeDObject

Method name CD Class SD Class Fitness value UML Model

computeArea(r, h) Cylinder Sphere 0.9375 3DObjectcomputeArea(l, b, h) Cuboid Cuboid 1 3DObjectvertice() Cuboid Cuboid 1 3DObjectcomputeArea(s) Sphere Cylinder 1.11 3DObjectcomputeArea() Cylinder Cylinder 1 ThreeDObject


an object. Sphere has no face, Cylinder has twofaces, Cuboid and Cube have 6 faces and Triangu-larPrism has 5 faces. Constraints are defined forthe methods and expressed as preconditions inobject constraint language. The preconditions forthe method computeArea() in the classes Cuboid,Cube, Sphere, TriangularPrism and Cylinderstate that the value of the attribute face shouldbe equal to 6, 6, 0, 5 and 2, respectively. Asthe signatures of all the methods involved indynamic polymorphism are the same, it is impos-sible to detect inconsistency by comparing themethod signatures. The guard conditions and thepreconditions are compared and method invoca-tion inconsistency is detected with the methodcomputeArea() invoked on the objects of classesCuboid, Sphere and Cylinder. The method com-puteArea() invoked on the object of class Sphereshould satisfy the guard condition face = 6 whichis not true resulting in run time errors. The in-vocation of the method computeArea() on theobject of class TriangularPrism is consistent asthe value of the attribute face in the guard con-dition and precondition is equal to 5.

The inconsistent method invocations in Fig-ures 1 and 2 result in wrong value for Area. If themodels are used in the cost estimation of buildings,the estimated cost will be computed with wrongvalues of area. The cost estimation will producea wrong value affecting the feasibility of theproject. Since the design errors are propagated tothe code generation phase, the software generatedwill have errors. Identifying the source of errorsin the code and fixing the errors is more difficult,time consuming and costly than detecting the

errors in the software design. Errors detected inthe testing phase may delay the software project.The errors identified during the testing phase orafter delivery of the software product increasesthe time to market as well as development andmaintenance cost of the software.

4. Architecture of the consistencyhandling system

PSO is an intelligent algorithm that can be usedin scientific and engineering area [51]. Consis-tency checking is formulated as an optimizationproblem with a maximizing fitness function thatoperates on the diagram specification. An opti-mization problem maximizes or minimizes a fit-ness function subject to the condition that theconstraints are satisfied. In our approach thefitness function represents the consistency andcompleteness of method invocations. The aimof the SRPSO algorithm is to optimize the con-sistency of polymorphic method invocations insequence diagram subject to the constraint thatthe methods are invoked on the right classes. TheSRPSO algorithm is preferred because it doesnot require transformation of models and canbe directly applied on UML model specification.The inconsistent particles are guided by the bestparticles to achieve consistency and hence searchspeed is high [52].

The architecture of the system to performconsistency checking using SRPSO is describedin Figure 3. The algorithms are implemented inJava running on a windows platform. The con-

Figure 3. Architecture of Consistency Checking System


sistency checking system comprises of UML toolto model the requirements, parser to generatediagram specification and consistency checker todetect method-invocation inconsistency and fixthe inconsistency using SRPSO algorithm.

4.1. UML tool

The requirements of the system to be designedare gathered and modelled into graphical rep-resentations using a UML tool. Several UMLmodelling tools like Magic Draw, Rational Soft-ware Architect, Agro UML, Papyrus etc. areavailable for modelling software. Our methodcan be integrated with any tool that give XMIformat. The models are saved in XMI format.The static and dynamic aspects are representedusing class diagram and sequence diagram. Classdiagrams represent the information regardingthe classes required to implement a system andthe type of relationship that exists between theclasses. The attributes and operations describethe properties and behaviour of the objects ofa class. Preconditions associated with methodinvocations are also represented. The precondi-tions of the overridden methods in the super classand subclass are different [50]. Sequence diagramrepresents the dynamic aspects by portraying theinteractions in the form of messages/ methodsbetween objects and the ordering of the interac-tions to produce a desired outcome. Polymorphicbehaviour can be represented using a sequencediagram by controlling the polymorphic invoca-tions with guard conditions.

4.2. Parser

The parser parses the UML model and producesspecifications of the diagrams. We have used theDocument Object model (DOM) parser to parsethe diagrams saved in XMI format. A class dia-gram specification comprises of the classes, thetype of association between the classes, attributesand methods of each class and the preconditionsfor method invocations. The sequence diagramspecification consists of the objects in the se-quence diagram, messages, sender and receiverof each message, the guard conditions on the

message invocations and the order of methodinvocations.

4.3. Consistency checker

The design inconsistencies in polymorphicmethodinvocations are detected by consistency checkermodule. Although the focus is on detection ofinconsistencies in polymorphic methods, the algo-rithm detects inconsistencies in polymorphic andnon-polymorphic methods. The specifications ofclass and sequence diagrams are input to the con-sistency checker. Inconsistencies are detected bya fitness function. The inconsistency is resolvedby reassigning methods with the SRPSO algo-rithm. Consistency checking is a two-step process:a) inconsistency detection and b) inconsistencyfixing.

4.3.1. Inconsistency detection

The fitness function, fs computes the fitnessvalue of the methods to detect inconsistency.The fitness value is computed as a function ofthe class name, method signature and propertiesof the method. The sequence diagram method isdefined in terms of its properties like name, id,parameters, sender, receiver, guard and a numberthat represents the message order. Each methodhas a specific value for a property (denoted asweight) and each position in the vector corre-sponds to one property of the method. The valuesfor the properties are set as 5, 3, 5, 5, 5, 4 and 3,respectively. The fitness function fs computes thefitness value of each sequence diagram method.A method invocation is classified as inconsistentif the fitness value is not equal to one. The fitnessfunction is defined with equation 1 as

fs =

(m∑

i=1ti ∗ wi) ∗ (wn + wcs +

n∑k=1

wk ∗ pk

)

W ∗

q∑j=1

wj ∗ pj

(1)

where ti represents the property i of methodspecification, wi represents the weight of theproperty ti, wn represents the weight value as-


sociated with the method name n, pj and wj

represents the position and weight of parame-ter j of the method n in the class diagram, pk

and wk denotes the position and weight of theparameter k of the method n in the sequencediagram, wcc represents the class name of themethod in the class diagram, wcs represents theclass name of the object on which the methodis invoked in sequence diagram and W repre-sents the weight assigned to a complete methodspecification. The value of W is set as 30. A com-plete method specification has values for all itsproperties. Unique values are assigned as theweights for method names, class names and datatype of parameters. Distinct method names, datatypes and classes have distinct weight. All poly-morphic methods have the same weight valuefor name and any numerical value can be se-lected to correspond to wn. The UML model inFigure 1 has a polymorphic method with namecomputeArea. The value of wn is set as 5. Thevalue of wn for the method names vertices() andperimeter() are set as 3 and 4, respectively. Theclasses are assigned weights in the range [1 . . . n]where n is the number of classes. Each class hasa unique weight. A class name present in boththe class diagram (wcc) and sequence diagram(wcs) has the same weight. The UML model inFigure 1 has four classes Cuboid, Sphere, Cylin-der and ThreeDShape and the weight values forthe classes Cuboid, Sphere, Cylinder and Three-DShape are 1, 2, 3 and 4, respectively. The weightvalue of parameter is defined as the number ofbytes required for the storing the data type ofthe parameter and the weights of char, int andfloat are defined as 1, 2 and 4, respectively. Theweights assign unique numerical values to themethod name, class name and data types of theparameters. The fitness value computation forthe methods in the sequence diagram of Figure 1and 2 is illustrated in Table 1.

Method invocation inconsistency is detectedwith the methods computeArea(r, h) and com-puteArea(s) since the fitness values of the meth-ods are not equal to one. The methods com-puteArea(l, b, h) and vertices() are consistentsince the fitness values are equal to one. Althoughinconsistency is detected from the fitness value in

static polymorphism, fitness value alone does notreveal inconsistency in dynamic polymorphism.Irrespective of the object on which the methodis invoked, the fitness value of the method com-puteArea() in the UML model ThreeDObject isone since the method is overridden in the childclasses. Hence, validation of the guard condi-tion and method precondition is necessary. Theguard condition and precondition are representedas tuples consisting of attribute, operator-valuepairs. Depending on the precondition, there canbe more than one operator-value pair. The tu-ples are compared to identify inconsistency. Thetuple corresponding to the guard condition forthe method computeArea() in Figure 2 in thesequence diagram invoked on the object of classCylinder is (face, (=, 0)). The tuple represen-tation for the precondition of the method com-puteArea() in the class Cylinder is (face, (=, 2)).There is a mismatch in the value of the attributeface and method invocation inconsistency is de-tected.

4.3.2. Inconsistency fixing with SRPSO

The inconsistency is resolved by identifying theright classes and remodelling the sequence dia-gram by replacing the inconsistent method in-vocations with consistent method invocationsusing SRPSO. To identify the right class, wecompute the cohesion of the attributes of theinconsistent method to all the classes in theclass diagram. The inconsistent method is re-assigned to the class with the highest cohesionvalue. The cohesion value between the method at-tributes and the class attributes is computed foreach method-class pair. The method attributesMA(m) of method m are derived from the pa-rameters of the method. The class attributesof class C, CA(C) are obtained from the classspecification. The cohesion value of a method mto class C is computed using equation 2 as

cohesion(m,C) = n(CA(C) ∩MA(m))n(MA(m)) (2)

where CA(C) represents the attributes definedin class C, MA(m) represents the attributes ofmethod m and n represents the number of at-


tributes. The SRPSO algorithm iterates until allthe method definitions are complete and consis-tent. The sequence diagram is remodelled duringiterations of the SRPSO algorithm. With staticbinding, the cohesion value determines the classto which an inconsistent method is to be reas-signed whereas in dynamic binding, the cohesionvalue and guard condition together determinethe class to which the method belongs.

5. Consistency handlingwith SRPSO algorithm

SRPSO is a bio-inspired metaheuristic techniquethat can provide better results than exact tech-niques even with increased size of search space.Metaheuristic techniques are more effective infinding software errors utilizing less number ofresources when compared with exact techniques[53]. SRPSO is an intelligent, optimization proce-dure in which the solution space contains a swarmof particles and the optimum value is attainedby an iterative process of updating generations.The particles occupy a position in the solutionspace. They have a velocity, a fitness value andthe particles update their velocity and positionbased on the direction of a) the previous velocity,b) the personal best position and c) position ofthe global best [54]. The fitness function deter-mines how close a particle is to the optimumsolution by computing the fitness value. Thevelocity directs the movement of particles andduring each iteration of the SRPSO algorithmthe particles compute their new velocity. Theposition is updated using the new velocity andwith each position update the particle moves toa better position. The process is iterated untilan optimum solution is reached.

5.1. Fitness function

The fitness function is an integral part of theSRPSO algorithm and it determines how closea particle is to the optimum solution. We havedefined a maximizing fitness function, fs to de-tect and fix method invocation inconsistency.The fitness function is defined with equation 1.

The consistency and completeness of a sequencediagram method is computed using the fitnessfunction. The invocations of inconsistent meth-ods are removed from the sequence diagram andthe inconsistent methods are added to the set ofinconsistent methods (IM).

5.2. Particle creation

The search space of the SRPSO algorithm is ini-tialized with particles. The proposed approachfocuses on inconsistency in polymorphic andnon-polymorphic method invocations and hence,the methods invoked in the sequence diagram aretreated as particles. A sequence diagram methodis specified using a set of properties and is rep-resented as a vector. The representation of thesequence diagram method (SeqM) is SeqM =[name id param sender receiver guard number]

The representation of SeqM consists ofa method name, a unique xmi id, the parameters,sender class of the method, receiver class of themethod, guard condition for method invocationand number representing the message order inthe sequence diagram. Each method has a spe-cific value for a property and each position inthe vector corresponds to one property of themethod. The values for the properties are fixed as5, 3, 5, 5, 5, 4 and 3, respectively. Any numericalvalue can be used to represent a property. Therestriction is that the value of W should be equalto the sum of the numerical values assigned tothe properties. The inconsistent methods in theset IM are represented as particles.

5.3. Velocity and position update

The particles in the search space are characterizedby a position and velocity. A particle is defined interms of its properties and in our approach; theposition of a particle represents the number ofproperties defined for the particle. The specifica-tion of the inconsistent particle initially has onlyone property, name and hence, the value of posi-tion is one. As the iteration progresses, dependingon the value of velocity the particle specificationwill be updated with its properties like id, sender,receiver etc. The number of properties of the par-


ticle to be updated in one iteration is determinedby the value of velocity. If the value of velocityis one, one property will be added to the particlespecification and position will be incremented byone. Velocity of the best particle is computed withequation 3, velocity of the rest of the particleswith equation 4, position is updated using theequation 5 and inertia weight with equation 6.

Vk(t+ 1) = ωk + Vk(t) (3)

Vk(t+ 1) = ωk + Vk(t) + a1 ∗ r1 ∗ (pBestk

−Xk(t)) + a2 ∗ r2 ∗ pso ∗ (gBest−Xk(t)) (4)Xk(t+ 1) = Xk(t) + Vk(t+ 1) (5)

ωk(t) ={ωk + η∆ω for best particleωk −∆ω otherwise

(6)

where Vk(t) represents the velocity of particle k attime t, a1 and a2 are the acceleration coefficients,r1 and r2 are the random numbers, Xk(t) repre-sents the position of particle k at time t, pBestk

represents the personal best of particle k and gBestthe global best of all the particles in the swarm,pso is the perception for the social cognition, ωk

is the inertia weight of the kth particle, ∆ω =(∆ωI −∆ωF )/Itr , ∆ωI = 1.05 and ∆ωF = 0.5,Itr is the number of iterations, and η = 1 is theconstant to control the rate of acceleration.

5.4. Stopping criteria

The SRPSO algorithm resolves method invoca-tion inconsistency. The algorithm iterates untilmethod invocation inconsistency is resolved orthe number of iterations reaches a maximumlimit. We have defined a variable method con-sistency count (MCC) that keeps track of thenumber of methods with consistent and completeinvocations. MCC is incremented if fitness valueof a method is equal to one. If MCC is equal tothe number of inconsistent methods in the setIM, method invocation inconsistency is resolved.

5.5. Algorithm

The consistency checking algorithm for polymor-phic methods is outlined in algorithm 1.

Algorithm 1: Consistency CheckingBeginInitialize SRPSO parameters, IM = φ

for each method, m in sequence diagram doidentify sender class, SC(m) and receiver class,RC(m)compute fs(m) with equation 1Case I: fs(m) == 1

if guard conditions do not matchIM = IM ∪ {m}

endifCase II: fs(m) 6= 1

IM = IM ∪ {m}endforidentify the receiving classfor each method, m in set IM do

identify method attributes, MA(m)for each class, Ci in class diagram do

determine class attributes CA(Ci)endforcompute cohesion(m, Ci)RCnew = Cj where Cj = max(cohesion(m, Ci),

i = 1 to number of classesdelete sequence diagram invocation for the

method mendforInitialize the search space with particles in the setIMrepeat

for each particle k in IM docompute fitness of particle kif (fs(Xk) > fs(pBestk))

pBestk = Xk(t)endifif (fs(Xk) > fs(gBest))

gBest = Xk(t)endifCompute inertia weight using equation 6Update velocity of gBest particle using equa-

tion 3for each particle except gBest particle do

Generaterandomnumber,rbetween 0and 1if (r > 0.5)pso = 1 else pso = 0

endifCompute velocity using equation 4

endforif(Vk(t+ 1) > 1


Vk(t+ 1) = 1 else Vk(t+ 1) = 0endifUpdate position using equation 5if (fs(Xk(t+ 1)) == 1)

Increment MCCendif

endforIncrement iteration count, Itr

until Itr = maxCount or MCC = number of incon-sistent methodsEnd

The algorithm initializes the search spacewith particles and SRPSO parameters. The ac-celeration coefficients are set as 1.49445 [5], Itr isinitialized as zero, W is set as 30 and maxCountis set as 35. The set IM is initialized to null. Thealgorithm computes the fitness values of methods.The guard conditions and preconditions of meth-ods are also validated. The inconsistent methodnames are added to the set IM and the inconsis-tent method invocations are removed from thesequence diagram.

To fix the inconsistency, the inconsistentmethods in the set IM are treated as new par-ticles and the position of the particles are ini-tialized. The cohesion of each method in the setIM to the different classes of the class diagramis computed to identify the new receiving class,RCnew. The class with the maximum cohesionvalue is identified as RCnew. The receiving classis identified from the precondition and cohesionvalue in dynamic polymorphism.

The newly created particles are inconsistentsince its properties are not completely specified.Initially, all the inconsistent particles have onlyone property, its name. The fitness values of theparticles in their current position are computedusing the fitness function, fs. If the current po-sition is better than the personal best (pBest)position of the particle, the personal best positionof the particle is updated. If the current positionis better than the global best (gBest) positionof all the particles in the swarm, the global bestposition is updated. New velocity and positionof the particles are computed. Depending onthe velocity value, properties such as id, sender,receiver etc. are added to the particle specification.The velocity component determines the number

of properties to be updated in one iteration. If thefitness value is equal to one, the method consis-tency count is incremented. The velocity, position,fitness value, pBest and gBest values of all theparticles in the set IM are updated during aniteration of the algorithm. The iteration count isalso incremented. The SRPSO algorithm iteratesuntil the method consistency count is equal tonumber of particles in the set IM or maximumnumber of iterations is reached. The updation ofthe properties of the inconsistent particles ensuresthat inconsistencies are resolved and the methodspecification is complete. The SRPSO algorithmefficiently detects and resolves inconsistency.

6. Results and discussions

The consistency checking algorithm is appliedto the UML models to detect method invoca-tion inconsistency. The UML model in Figure 1contains the polymorphic method computeArea.The method-invocation inconsistency detectionmodule detects two inconsistent methods: com-puteArea(r, h) and computeArea(s) by comput-ing the fitness values of the methods. The incon-sistent methods are added to the set IM and thesequence diagram invocations of the inconsistentmethods are removed. The attributes requiredfor the implementation of the method are derivedfrom the parameters of the method. The cohesionof the method attributes to the different classesin the class diagram is computed. The cohesionvalues of the inconsistent methods to differentclasses are represented in Table 2.Table 2. Cohesion Value for UML Model 3DObject

Method Class NameCube Cuboid Cylinder

computeArea(r, h) 0.0 f 0.5 1.0computeArea(s) 1.0 0.0 0.0

The class Cylinder has the highest cohesionvalue for the method computeArea(float, int)and the class Cube has the highest cohesionvalue for the method computeArea(int). The re-ceiving class of the inconsistent method com-puteArea(r, h) is identified as class Cylinder


and the new receiving class of the method com-puteArea(s) is identified as class Cube. The se-quence diagram methods are specified with a setof properties. On detecting inconsistency, theproperties related to the method invocation ofthe inconsistent methods are also deleted. Theinconsistency is fixed during iterations of theSRPSO algorithm. During each iteration of theSRPSO algorithm, the specification of the se-quence diagram method in the set IM is updatedby adding the properties of the methods. The ap-proach ensures that method invocation inconsis-tency is resolved and the method specification iscomplete. The algorithm terminates when MCCbecomes equal to the number of inconsistentmethods or when Itr reaches the maxCount.

A graph representing the fitness value of theinconsistent methods computeArea(r, h) andcomputeArea(s) during different iterations of theSRPSO algorithm with acceleration coefficientvalues equal to 1.49445 is represented in Figure 4.The method computeArea(s) has a fitness value0.0925 during the first iteration of the algorithm.As the iteration count increases, the fitness valueof the particle increases. In iteration 8, the fitnessvalues of the two inconsistent particles becomeone and the UML model 3DObject is consistentin terms of polymorphic method invocation andspecification. The fitness value of the inconsis-tent method in the UML model ThreeDObject isrepresented in Figure 5. The algorithm is imple-mented with acceleration coefficient values equalto 1.49445 and converges in 8 iterations.

The result of implementation of the algorithmis represented in Figure 6. The XMI parser identi-

fies the methods present in each class of the classdiagram. The method computeArea() is overrid-den in all child classes. The signatures of the classdiagram method and sequence diagram methodsare compared and no inconsistency is detected.A further validation of guard conditions and pre-conditions identifies three inconsistent methodsdue to wrong guard conditions. The SRPSO algo-rithm resolves the inconsistencies in 8 iterationsand the sequence diagram specification has con-sistent method invocations with guard conditionsmatching the preconditions. The execution timeof the algorithm is 875 ms.

The UML model Deposit and Payroll Sys-tem used for evaluating the algorithm are rep-resented in Figures 7 and 8, respectively. TheUML model exhibits dynamic polymorphism,whereas the UML model Payroll system exhibitsstatic polymorphism. The UML model Deposithas three inconsistent method invocations. Themethod invocations are prefixed with the guardcondition. The UML model Payroll System has9 method invocations out of which 5 invocationsare inconsistent. The UML model Deposit inFigure 7 forms a part of the banking systemto compute the interest of term deposits. Themethod Interest() is overridden in the derivedclasses. The interest rate depends on the periodof the term deposit. The three method invoca-tions are inconsistent. Inconsistent design resultsin wrong values for the interest calculated andmaturity value. This creates a set of unsatisfiedcustomers and affects the credibility of the bank-ing system. Inconsistent design results in thecreation of software with faults. This affects the

Figure 4. Fitness Values of Inconsistent Methodsfor UML model 3DObject

Figure 5. Fitness Values of Inconsistent Methodsfor UML model ThreeDObject


Figure 6. Handling Inconsistencies for the UML model ThreeDObject

Figure 7. UML Model Deposit

software quality. The errors may be identifiedeither during the testing phase or after deliveryof the product, which increases the software de-vlopment cost, maintenance cost, and time tomarket the software.

The algorithm is evaluated based on twocriteria: convergence and execution time. Theconvergence of the algorithm is evaluated basedon the number of iterations required to resolveinconsistency. Inconsistency is resolved when the


Figure 8. UML Model Payroll System


Table 3. Execution Time and Convergence

Number ofUML Model Polymorphism Methods Inconsistent Iteration Avg. Running

Type Invocations Count Time(ms)

Deposit Dynamic 3 3 8 7643DObject Static 4 2 8 954ThreeDObject Dynamic 4 3 8 984Course Registration System Dynamic 12 6 7 850Payroll System Static 9 5 7 998Demonstrative Sample Static 12 7 8 1052

fitness values of all particles in the swarm areequal to one. We have modelled different casestudies and the algorithm is experimented ondifferent inconsistent models exhibiting staticand dynamic polymorphism. Table 3 representsthe execution time and convergence of the al-gorithm on different UML models. The tablerepresents the UML models, the type and num-ber of inconsistencies present in the models, thenumber of iterations required to converge, andthe average running time of the algorithm. Theexecution time of the algorithm is computed onan Intel Core i7 CPU running at 2.80 GHz with4 GB primary memory. The UML model Depositrequires an average running time of 764 ms toachieve consistency; the average running time ofUML model 3DObject and ThreeDObject are954 ms and 984 ms, respectively. The UML model3DObject exhibits static polymorphism and has 4method invocations out of which two invocationsare inconsistent. Models Deposit and ThreeDOb-ject exhibit dynamic polymorphism. The UMLmodel Demonstrative Sample has polymorphicand non-polymorphic methods. Inconsistenciesin non-polymorphic methods are detected fromthe fitness value computation. The results showthat the average time taken by the algorithmto detect and fix inconsistencies in polymorphicmethods is of the order of milliseconds and thealgorithm converges in all cases.

Table 4 represents the statistical evaluationresults of the algorithm. The values of mean,standard deviation and variance are computedfor different values of acceleration coefficients.The algorithm is statistically evaluated on theUML model and better results are obtained withacceleration coefficient values equal to 1.49445.

The evaluation results have shown that the algo-rithm detects and fixes all inconsistent methodinvocations. As a result, no false positives or falsenegatives are detected. Hence the precision andrecall values are high and equal to the one in ourapproach.

Inconsistency handling has a prime role in thedevelopment of quality software. Polymorphismmakes the design extensible. It simplifies thedesign and enables the addition of new functionswithout creating additional overheads. Inconsis-tencies arising due to method invocation inconsis-tency of polymorphic methods are hard to detect.We have presented an AI based approach that de-tects and fixes inconsistency in polymorphic andnon-polymorphic methods. Our approach pro-vides significant role in ensuring software designconsistency. The proposed approach of incon-sistency detection has a number of advantages.The method operates on a specification of thediagram and uses a direct approach of detectingand fixing inconsistencies without transformingthe model to an intermediate representation. Theapproach detects and fixes method invocation in-consistency in polymorphic and non-polymorphicmethods. The fitness function uses simple calcula-tions. Addition of new rules requires only a redef-inition of the fitness function. Inconsistencies arefixed by identifying the receiver class from the co-hesion values and guard conditions and redefiningthe method invocations in the sequence diagram.The algorithm is fast and computationally inex-pensive. As the inconsistencies are detected andfixed in the design phase, the errors are not prop-agated to the code generation phase. Hence, thedevelopment and maintenance costs are reducedand quality of the code can be improved.


Table 4. Statistical Evaluation of the Algorithm

UML Model Parameter a1 = a2 = 1.49445 a1 = a2 = 14 Runs 7 Runs 4 Runs 9 Runs

3DObjectMean 0.4685 0.95 0.2768 1SD 0 –5.551E–17 0 0Variance 0.017292 0.0025 0.003624 0

ThreeDObjectMean 0.544444 0.9333333 0.488889 1SD –3.70E–17 –1.110E–16 0 0Variance 0.00617 0.0022222 0.000202 0

DepositMean 0.65556 0.95556 0.4888809 1SD 0 3.701E–17 –1.850E–17 0Variance 0.006173 0.003951 0.00617284 0

Course Registration SystemMean 0.711111 1 0.416667 0.911111SD 0 0 9.2519E–18 –3.701E–17Variance 0.006173 0 0.001389 0.003951

Payroll SystemMean 0.7 1 0.413333 1SD 0 0 –1.110E–17 0Variance 0.006667 0 0.0016 0

7. Threats to validity

The section deals with threats to validity.External Validity concerns with how the

result of the experiments can be generalized toother environments. As part of the evaluation, wehave evaluated the algorithms on UML modelsinvolving polymorphic method invocations. Theproposed approach detects and fixes inconsisten-cies involving static and dynamic polymorphicmethod invocations. The algorithm canbe general-ized to detect inconsistencies in non-polymorphicmethod invocations and handle other inconsis-tencies involving sequence diagrams. The gen-eralization can be performed by modifying thefitness function. This argument is substantiatedby describing how another inconsistency relatedto the class and sequence diagram is handled. Theconsistency rule states that two objects in the se-quence diagram interact only if there is an associ-ation in the class diagram between the interactingobjects. The fitness function can be modified toinclude another term comprising of the senderand receiver classes in the class and sequencediagram. The proposed approach models inconsis-tency handling as an optimization problem anddetecting inconsistencies with fitness function.The algorithm can be expanded to detect and

fix intra-model inconsistencies among differentdiagrams. We have defined the fitness function interms of the properties of the inconsistent modelelements. Inconsistency detection among differentdiagrams requires definition of the fitness functionin terms of the properties of the inconsistentmodelelement and a particle representation has to beformulated for the inconsistent model element interms of its properties.

Construct Validity refers to the extent towhich the experiment setting reflects the theory.We are able to successfully implement the algo-rithm on a set of UML models involving staticand dynamic polymorphic method invocations.The fitness functions are defined with the aim ofdetecting method invocation inconsistencies andinconsistencies are identified and resolved accu-rately. The UML models are a representative ofthe models on which a consistency check can beperformed. The number of inconsistencies in theUML models varies from 3 to 7 and the numberof method invocations varies from 3 to 12.

Internal Validity represents the extent towhich the casual relationship established can-not be explained by other factors. The casualrelationships between class diagram method sig-nature and sequence diagram method signatureare analyzed to detect inconsistency. Method


invocation inconsistency arises due to the invoca-tion of a method on an object of a class in whichthe method is not defined. Fitness function isdefined in terms of the method signature andclass names. Hence, the method signature is themajor component in inconsistency detection andthe casual relationship between method signa-tures is exploited to detect inconsistencies. In thecase of dynamic polymorphism, since the methodsignatures of the polymorphic methods are thesame, a further comparison of guard conditionsand constraints is performed.

Conclusion Validity: We have performeda statistical evaluation of the algorithm and theresults are summarized in Table 4. The modelsused for evaluation are a representative of theUML models used in the design of software sys-tems. The statistical evaluation results show thatthe algorithm converges in less number of itera-tions with acceleration coefficient values equal to1.49445. The convergence of the algorithm andexecution time are also computed. The averageexecution time is of the order of milliseconds andthe number of iterations required for the algo-rithm to converge is independent of the numberof method invocations or the number of inconsis-tencies.

8. Conclusion

With the increasing relevance of software in in-dustries and manufacturing, the complexity andsize of the software and the complexity of thedesign has increased. Developing quality softwareis one of the major challenges faced by softwaredevelopers. One of the definitions of quality soft-ware is fitness for purpose and quality softwareshould be able to function as per the user′s re-quirements. One of the key aspects to ensuringsoftware quality is good design. Inconsistent de-sign leads to the generation of software withfaults. A periodic review of the software designis one the factors that can enhance the softwarequality and reduce software failures thereby im-proving manufacturing and productivity. The re-view helps to detect inconsistencies and fix the in-consistencies. Polymorphism is an important fea-

ture that makes the software design compact andextensible. It is hard to trace the polymorphismas it is often detected at run time. We introducean intelligent automated approach that uses theSRPSO algorithm to detect and fix inconsistencyin polymorphic methods. The algorithm is evalu-ated on different case study involving static anddynamic polymorphism. The method detects andfixes inconsistencies in all cases. Analysis of theresults shows that the inconsistency detectionand fixing in our approach is quick, easy, andeffective. The proposed approach has a numberof advantages. The algorithm can be invokedafter the application is modelled or during andafter refinements to the models. The methodoperates directly on the diagram specificationand does not require transformation to anotherrepresentation. Addition of new rules requiresonly a redefinition of the fitness function. Thefitness function uses simple calculations. Thetime required to detect and fix inconsistenciesis of the order of milliseconds. The inconsisten-cies developed in the design are detected andcorrected in the same phase. Maintenance costof software is a huge burden for manufacturingindustries. Automatic detection of inconsisten-cies in polymorphic methods during the designphase ensures quality of the code produced andreduces development and maintenance cost ofthe software.

References

[1] M. Harman, “The role of artificial intelligencein software engineering,” in First InternationalWorkshop on Realizing AI Synergies in SoftwareEngineering (RAISE). IEEE, 2012, pp. 1–6.

[2] M. Harman and B.F. Jones, “Search-based soft-ware engineering,” Information and SoftwareTechnology, Vol. 43, No. 14, 2001, pp. 833–839.

[3] O. Raiha, “A survey on search-based softwaredesign,” Computer Science Review, Vol. 4, No. 4,2010, pp. 203–249.

[4] J. Kennedy and R. Eberhart, “Particle swarmoptimization,” in Proceedings of IEEE Interna-tional Conference on Neural Networks. IEEE,1995, pp. 1942–1948.

[5] M.R. Tanweer, S. Suresh, and N. Sundararajan,“Self regulating particle swarm optimization al-


gorithm,” Information Sciences, Vol. 294, 2015,pp. 182–202.

[6] P. Stevens and R.J. Pooley, Using UML: Soft-ware engineering with objects and components.Pearson Educationr, 2006.

[7] R. France and B. Rumpe, “Model-driven develop-ment of complex software: A research roadmap,”in Future of Software Engineering. IEEE Com-puter Society, 2007, pp. 37–54.

[8] B. Selic, “The pragmatics of model-driven devel-opment,” IEEE Software, Vol. 20, No. 5, 2003,pp. 19–25.

[9] C. Pons, L. Olsina, and M. Prieto, “A for-mal mechanism for assessing polymorphism inobject-oriented systems,” in Proceedings of FirstAsia-Pacific Conference on Quality Software.IEEE, 2000, pp. 53–62.

[10] A. Egyed, “Fixing inconsistencies in UML de-sign models,” in 29th International Conferenceon Software Engineering (ICSE’07). IEEE, 2007,pp. 292–301.

[11] A. Egyed, E. Letier, and A. Finkelstein, “Gener-ating and evaluating choices for fixing inconsis-tencies in UML design models,” in Proceedingsof the 23rd IEEE/ACM International Confer-ence on Automated Software Engineering. IEEEComputer Society, 2008, pp. 99–108.

[12] A. Egyed, “Automatically detecting and trackinginconsistencies in software design models,” IEEETransactions on Software Engineering, Vol. 37,No. 2, 2011, pp. 188–204.

[13] Q. Long, Z. Liu, X. Li, and H. Jifeng, “Con-sistent code generation from UML models,” inProceedings of the Australian Software Engineer-ing Conference. IEEE, 2005, pp. 23–30.

[14] L.C. Briand, Y. Labiche, and L. O’Sullivan, “Im-pact analysis and change management of UMLmodels,” in Proceedings of the International Con-ference on Software Maintenance, ICSM 2003.IEEE, 2003, pp. 256–265.

[15] R. Kretschmer, D.E. Khelladi, A. Demuth,R.E. Lopez-Herrejon, and A. Egyed, “Fromabstract to concrete repairs of model incon-sistencies: An automated approach,” in 24thAsia-Pacific Software Engineering Conference(APSEC). IEEE, 2017, pp. 456–465.

[16] A. Rountev, A. Milanova, and B.G. Ryder,“Fragment class analysis for testing of polymor-phism in Java software,” IEEE Transactionson Software Engineering, Vol. 30, No. 6, 2004,pp. 372–387.

[17] D.K. Saini, “Testing polymorphism in objectoriented systems for improving software quality,”ACM SIGSOFT Software Engineering Notes,Vol. 34, No. 4, 2009, pp. 1–5.

[18] R. Kaur and J. Sengupta, “Software process mod-els and analysis on failure of software develop-ment projects,” arXiv preprint arXiv:1306.1068,2013.

[19] K.A. Briski, P. Chitale, V. Hamilton, A. Pratt,B. Starr, J. Veroulis, and B. Villard, “Minimiz-ing code defects to improve software quality andlower development costs,” Development Solu-tions White Paper, IBM, 2008.

[20] P. Jalote, “An integrated approach to softwareengineering,” Springer Science and Business Me-dia, 2012.

[21] B. Nuseibeh, S. Easterbrook, and A. Russo,“Making inconsistency respectable in softwaredevelopment,” Journal of Systems and Software,Vol. 58, No. 2, 2001, pp. 171–180.

[22] A. Reder and A. Egyed, “Incremental consis-tency checking for complex design rules andlarger model changes,” in International Con-ference on Model Driven Engineering Languagesand Systems. Springer, Berlin, Heidelberg, 2012,pp. 202–218.

[23] M.R. Ehrenleitner, A. Demut, and A. Egyed,“Towards model-and-code consistency checking,”in 38th Annual Computer Software and Applica-tions Conference. IEEE, 2014, pp. 85–90.

[24] N. Macedo, T. Jorge, and A. Cunha, “A fea-ture-based classification of model repair ap-proaches,” IEEE Transactions on Software En-gineering, Vol. 43, No. 7, 2017, pp. 615–640.

[25] J.P. Puissant, R.V.D. Straeten, and T. Mens,“A regression planner to resolve design model in-consistencies,” in European Conference on Mod-elling Foundations and Applications. Springer,Berlin, Heidelberg, 2012, pp. 146–161.

[26] F.J. Lucas, F. Molina, and A. Toval, “A sys-tematic review of UML model consistency man-agement,” Information and Software technology,Vol. 51, No. 12, 2009, pp. 1631–1645.

[27] D. Kalibatiene, O. Vasilecas, and R. Dubauskaite,“Rule based approach for ensuring consistency indifferent UML models,” in EuroSymposium onSystems Analysis and Design. Springer, Berlin,Heidelberg, 2013, pp. 1–16.

[28] C.F. Borbaand and A.E.A. Da Silva, “Knowl-edge-based system for the maintenance registra-tion and consistency among UML diagrams,” inBrazilian Symposium on Artificial Intelligence.Springer, Berlin, Heidelberg, 2010, pp. 51–61.

[29] D. Torre, Y. Labiche, and M. Genero, “ML con-sistency rules: A systematic mapping study,” inProceedings of the 18th International Confer-ence on Evaluation and Assessment in SoftwareEngineering. Springer, Berlin, Heidelberg, 2014,pp. 1–10.


[30] R.J. Ma, N.Y. Yu, and J.Y. Hu, “Applicationof particle swarm optimization algorithm in theheating system planning problem,” The Scien-tific World Journal, 2013, pp. 1–11.

[31] S. Pandey, L. Wu, S.M. Guru, and R. Buyya,“A particle swarm optimization-based heuristicfor scheduling workflow applications in cloudcomputing environments,” in 24th IEEE In-ternational Conference on Advanced Informa-tion Networking and Applications. IEEE, 2010,pp. 400–407.

[32] D.Y. Sha and H.H. Lin, “A multi-objective PSOfor job-shop scheduling problems,” Expert Sys-tems with Applications, Vol. 37, No. 2, 2010,pp. 1065–1070.

[33] M. Gong, Q. Cai, X. Chen, and L. Ma, “Complexnetwork clustering by multiobjective discreteparticle swarm optimization based on decom-position,” IEEE Transactions on EvolutionaryComputation, Vol. 18, No. 1, 2014, pp. 82–97.

[34] N.K. Sharma, D.S. Babu, and S.C. Choube,“Application of particle swarm optimizationtechnique for reactive power optimization,” inIEEE-International Conference on Advancesin Engineering, Science and Management(ICAESM-2012). IEEE, 2012, pp. 88–93.

[35] P. Sivakumar, S.S. Grace, and R.A. Azeezur,“Investigations on the impacts of uncertainwind power dispersion on power system stabil-ity and enhancement through PSO technique,”in International Conference on Energy Effi-cient Technologies for Sustainability. IEEE, 2013,pp. 1370–1375.

[36] F. Li, D. Li, C. Wang, and Z. Wang, “Net-work signal processing and intrusion detectionby a hybrid model of LSSVM and PSO,” in 15thIEEE International Conference on Communica-tion Technology. IEEE, 2013, pp. 11–14.

[37] Z. Jun and Z. Kanyu, “A particle swarm opti-mization approach for optimal design of PIDcontroller for temperature control in HVAC,” inThird International Conference on MeasuringTechnology and Mechatronics Automation. IEEE,2011, pp. 230–233.

[38] D.K. Saini and Y. Sharma, “Soft computingparticle swarm optimization based approach forclass responsibility assignment problem,” In-ternational Journal of Computer Applications,Vol. 40, No. 12, 2012, pp. 19–24.

[39] R. George and P. samuel, “Fixing class design in-consistencies using self regulating particle swarmoptimization,” Information and Software Tech-nology, Vol. 99, 2018, pp. 81–92.

[40] R. George and P. samuel, “Particle swarm op-timization method based consistency checkingin UML class and activity diagrams,” in Inno-vations in Bio-Inspired Computing and Applica-tions. Springer, Cham, 2016, pp. 117–127.

[41] R. George and P. Samuel, “Fixing state changeinconsistency with self regulating particle swarmoptimization,” Soft Computing, Vol. 24, No. 24,2020, pp. 18 937–18 952.

[42] M. Kessentini, H. Sahraoui, and M. Boukadoua,“Search-based model transformation by example,”Software and Systems Modeling, Vol. 11, No. 2,2012, pp. 209–226.

[43] A. Windisch, S. Wappler, and J. Wegener, “Ap-plying particle swarm optimization to softwaretesting,” in Proceedings of the 9th annual confer-ence on Genetic and evolutionary computation.ACM, 2007, pp. 1121–1128.

[44] R. Malhotra and A. Negi, “Reliability mod-eling using particle swarm optimization,” In-ternational Journal of System Assurance Engi-neering and Management, Vol. 4, No. 3, 2013,pp. 275–283.

[45] J.A. Parejo, A. Ruiz-Cortes, S. Lozano, andP. Fernandezi, “Metaheuristic optimizationframeworks: A survey and benchmarking,” SoftComputing, Vol. 16, No. 3, 2012, pp. 527–561.

[46] S. Milton and H. Schmidt, “Dynamic dispatchin object-oriented languages,” The AustralianNational University, Canberra, Technical ReportTR-CS-94-02, January 1994.

[47] E. Ernst and D.H. Lorenz, “Aspects and poly-morphism in AspectJ,” in Proceedings of the 2ndInternational Conference on Aspect-OrientedSoftware Development. ACM, 2003, pp. 150–157.

[48] D. Ancona, S. Drossopoulou, and E. Zucc, “Over-loading and inheritance,” in FOOL’ 01 – Inter-national. Workshop on Foundations of ObjectOriented Languages, 2001.

[49] D.P. Friedman, M. Wand, and C.T. Haynes,Essentials of Programming Languages, 2nd ed.,Prentice-Hall of India, 2001.

[50] R.V. Binder, “Testing object oriented software:A survey,” Software Testing, Verification andReliability, Vol. 6, No. 3–4, 1996, pp. 125–252.

[51] D.P. Rini, S.M. Shamsuddin, and S.S. Yuha-niz, “Particle swarm optimization: technique,system and challenges,” International journalof computer applications, Vol. 14, No. 1, 2011,pp. 19–26.

[52] Q. Bai, “Analysis of particle swarm optimizationalgorithm,” Computer and information science,Vol. 3, No. 1, 2010, pp. 180–184.


[53] M. Ferreira, F. Chicano, E. Alba, andJ.A. Gomez-Pulido, “Detecting protocol errorsusing particle swarm optimization with Javapathfinder,” in Proceedings of the High Perfor-mance Computing and Simulation Conference(HPCS 08), 2008, pp. 319–325.

[54] D. Floreano and C. Mattiuss, “Bio-inspired ar-tificial intelligence: theories, methods, and tech-nologies,” MIT press, Aug 2008.

Documents

Fixing Design Inconsistencies of Polymorphic Methods Using