AN ANALYSIS ON SARKAR’S MODULARITY METRICS

Posted: August 26th, 2021

AN ANALYSIS ON SARKAR’S MODULARITY METRICS

By (Student’s Name)

(Course)

(Professor’s Name)

(University)

City (Date)

Date

An analysis of Sarkar’s Modularity Metrics

Introduction

            With the advent of object-based programming as a measure of complimenting the study of metamodels, it has become imperative that model-driven engineers code anti-patterns and metrics detect design flaws. Whereas anti-patterns have been designed to smell codes, metrics can regulate the complexity attached to object-based programming designs. Precisely, metrics measure the complexity that the smell codes have missed. Thus,  the paper provides an analysis of Sarkar’s modularity metrics concerning three critical levels of metamodels’ line of codes.

Association-Induced Coupling Metric

Sarkar expresses the association-based inter-module coupling (AC)with respect to how various classes have redefined its usageas they result from different modules in the public Application Program Interface (API) of a class (Hinkel & Strittmatter 2017, p.255). Therefore, the application of metamodels is coupled with the usage definition of the classes for interpretation of public API into a particular set of elements of a class. In this way, the usefulness of metamodels fosters the need for drawing distinctions that have existed between multiple types of induced-coupling associations. As opposed to the object-based platforms, the use of metamodels by Sarkar helps underscore the conspicuous difference between regular relationships and composite references, especially in Ecore (Hinkel & Strittmatter 2017, p.255). Therefore, Sarkar has inferred the meaning of computing the three association-based coupling indices separately. In this case, one computation goes hand in hand with only associations, another one for composite references, and the last one combines the computations of the two former techniques.

Just as the Inheritance-Coupling metric, Sarkar has defined the composite Association-based coupling metric as encompassing three elements – AC1, AC2, and AC3. Although these three components are almost similar to IC1, IC2, and IC3, they utilize the predicate U ses rather than Chlds and Par for the reason that they yield the sets of utilized classes of a particular class (Hinkel & Strittmatter 2017, p.255). Therefore, these metricsare adjusted coincidentally by changing the semantics of the usage predicate. Further, it has been demonstrated that the closest methods of adopting the AC are to incorporate different kinds of references as usages, thus deriving the metric AC^cmp(Hinkel & Strittmatter 2017, p.255). Mainly, therefore, this is done by restricting the usage to composite as well as container references, hence removing all the remainder non-composite cross-references.

Such kind of discrepancy seems important simply because composite references contain different qualities compared to cross-references in numerous metamodels like Ecore (Hinkel & Strittmatter 2017, p.255). However, the most significant difference results from the fact that composite references are majorly used to measure the lifecycle of referenced model components. Therefore, it is clear to understand that container references directly contrast with composite references in meaning and application. Thus, implying that the usage of AC^cmp would automatically put such recognition into effect. As an example, opposite references would bring about a strong coupling between the declaration of classes provided that they are container references (Hinkel & Strittmatter 2017, p.255). Most importantly, whenever a reference is considered useful in one of these classes; therefore, the opposite reference would attain a target value, too(Hinkel & Strittmatter 2017, p.255). In brief, Sarkar has inferred the existence of a separated third variant of the AC metric, which inherently determines how the opposite reference, AC^op introduces the association-based coupling metric.

Size Uniformity Metrics

            The size uniformity metrics, such as MU and CU,directly re-count the mean sizes of modules as well as the classes of the standard deviation. This is illustrated through the expression below.

{MU,CU}=

The denominator of the expression, which is given by µ{p,c}, and σ{p,c}signifies the mean value as well as the standard deviation associated with the different sizes of packages (Hinkel & Strittmatter 2017, p.255). The size of the number of classes is stressed in a package (MU: µp,σp)and sometimes in the methods or lines of codes (CU: µc,σc). Whereas there exist varied numbers of classes of a package that can be established with respect to metamodels, the number of techniques used in metamodels seems pointless. The reason is that metamodels centrally focuses on structural qualities like attributes and references. Therefore, the lines of code for a particular class would not seem applicable, simply because the definition of the metamodels is not based on textual syntaxes (Hinkel & Strittmatter 2017, p.255). Consequently, therefore, Sarkar emphasizes on the significance of adapting class uniformity given that the undertaken number of structural qualities contribute to the critical parts of the model class.

A Metric Related to System Extensibility

            Software designers can generate extensible systems whose attached functionality might be enhanced. Such enhancements involve syntax modification of the plugin form by adding new pieces of codes (Sarkar, Kak & Rama 2008, p.709). Therefore, the main idea of generating extensible systems is to avoid effecting changes in the best part of the software. Based on this analysis, for example, it is essential to consider a financial application whose main body has already been programmed in the exception of another part to be added via a plugin module. In this case, the addition of the plugin module would effectively facilitate the diversification of withdrawal modes of cash for customers (Sarkar, Kak & Rama 2008, p.709). Therefore, the application of the plugin-based method of adding a section of the code offers a chance for the integration of diverse withdrawal modes in case of the availability of large withdrawals. Indeed, this approach works best when the software has been customized according to the represented needs. Likewise, the plugin-based method is, in fact, a well-defined set of extensions APIs (E-APIs) describing a module that would execute the E-APIs (Sarkar, Kak & Rama 2008, p.709). Thus, the application of plugin-based design is evident in many commercial frameworks, such as the spring framework as well as the Eclipse plugin framework.

            Throughout this design method, inversion of control is meant to interrelate the working principles of modules and plugins. In this scenario, it is clear that the module invokes the behaviors of the plugins as opposed to having plugins define the API techniques of the module. For example, it is inferred that the plugin needs be so specific in classes and methods that it would extend a more certain functionality of the module (Gyimothy, Ferenc, &Siket 2005, p.905). Although it is common to view far more grown plugin modules in ad hoc modus over time, the initiation of the ad hoc “code bloat” would result in superfluously unneeded code by the plugin. Therefore, this metric seeks to measure the system extensibility of this phenomenon found in the code. Categorically, by considering pas a plugin module that executes a few E-APIs resulting from the framework module, p1(Gyimothy, Ferenc, &Siket 2005, p.905). Likewise, it is essential to regard I^E(p1), the set of E-APIs associated with implementing the plugin module via the host module p1. Moreover, the analysis of this system metric would also relate Abstract(m)as a theoretical method being executed by m of the plugin module (Sarkar, Kak & Rama 2008 p.710). Hence, the M(p) symbolizes all the approaches for measuring system extensibility of a plugin module, as illustrated in the function below.

ImplExtn (p) ={m ϵ M(p)| Ǝ_tϵI^E_(p1)Abstract(p) ϵ r}

Equally, with the expression of the function, it implies that all the involved method sets in p would usually execute a few E-API of the module p1(Sarkar, Kak & Rama 2008, p.710). For instance, it is argued that the constant calls initiated by methods of a module to other methods inside the plugin module p would impact a transitive closure with the same techniques. As a result, these module calls effectively equate the number of methods of p applied inside the plugin(Sarkar, Kak & Rama 2008, p.710). Therefore, it can be inferred that all the methods in p take an integral role in realizing the assigned functionality on the plugin code system.

Conclusion

            Analysis of Sarkar’s modularity metrics redefines object-oriented programming. The applied metrics have seemed useful in detecting the design flaws inside metamodels. The application of the association-induced coupling metric reinforcesthe need for execution metamodels coupled with the usage definition of the classes, thus interpreting the public API into a particular set of elements of a class.The analysis of size uniformity metrics measures the mean sizes and standard deviation of the design flaws. Lastly, the usability of a metric related to system extensibility determines the plugin module, hence adding certain parts of the code via syntax modification.

Works Cited

Gyimothy, T Ferenc, R & Siket, I 2005,’Empirical validation of object-oriented metrics on open source software for fault prediction,’IEEE Trans. Software Eng, vol. 31, no. 10, pp. 897- 910.

Hinkel, G & Strittmatter, M2017, ‘On using Sarkar Metrics to Evaluate the Modularity of Metamodels,’In Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2017), pp. 253-260

Sarkar, S Kak, CA & Rama MG 2008,’Metrics for measuring the quality of modularization of large-scale object-oriented software,’IEEE Transactions on Software Engineering, vol. 34, no. 5, pp. 700-720.