Measuring the Complexity of Product Configuration Systems Amartya Ghosh and Katrin Kristjansdottir and Lars Hvam1 and Γ‰lise Vareilles2 Abstract. 1 The complexity of product configuration systems is an estimation function that takes into account the impact of the important indicator of both development and maintenance effort of industry and the organization on the project and the size and the systems. Existing literature proposes a couple of effort complexity of the product under consideration. The activities estimation approaches for configurator projects. However, these associated with the PCS development project include modelling the approaches do not address the issues of comprehensibility and product structure and programming this model into a configuration modifiability of a configuration model. Therefore, this article proposes a metric to measure the total cognitive complexity of the software. However, this approach does not explicitly take into the configuration model corresponding to a product configuration consideration the complexity of the configuration model, while system, expressed in the form of an UML class diagram. This estimating the load required. Another approach to estimating the metric takes into account the number and the type of attributes, costs associated with PCS projects is to calculate the functional constraints and the relationships between classes in an UML class size of the UML class diagram of the configuration knowledge diagram. The proposed metric can be used to compare two base using the IFPUG Function Point Analysis (FPA) technique configuration models, in terms of their cognitive complexity. [7]. This approach, however, is subjective in nature with regards to Moreover, a relation between development time for a PCS project the definition of internal and external logical files (ILFs and ELFs). and the total cognitive complexity of the corresponding Moreover, the function point approach does not clarify the configuration model is established using linear regression. To definition of one unit of function point [8]. The parametric validate the proposed approach a case study is conducted where the cognitive complexity is calculated for two configuration models. complexity approach proposed in [5] involves calculating a metric on the basis of the number of business rules and the number of attributes, across two categories: field of engineering (sales, 1 Introduction engineering and/or both) and the integration to other IT systems. However, the parametric complexity approach fails to take into Information technology tools, such as product configuration account the complexity associated with the manner in which the systems (PCSs), are widely used to handle the increased amount of configuration problem has been modelled into a PCS. A method to information shared amongst customers, sales and production analyse the complexity of PCS is, therefore, needed. departments at companies, arising out of an increase in the demand This paper proposes a complexity metric that captures the of product customization [1]. PCSs are knowledge-based IT different aspects associated with the PCS by focusing on the systems which fulfil a configuration task. A configuration task is a cognitive complexity of the configuration model. The metric can special type of design activity [2] facilitated by a number of be used to effectively compare different PCS both developed on components, their corresponding properties and ports, and the same configuration software platforms or on different constraints which restrict the number of feasible combinations platforms. Also, the metric can be used to identify the impact of the associated with the components [3]. complexity on the resource consumption for the development and PCSs contain detailed information about the companies’ maintenance activities associated with the PCS. Given that offerings. The information included in the configuration models resources required for these activities are valuable and have limited depend on the type of the configuration system and usually include availability, it is imperative that practitioners in the field have some different components, attributes and rules of how the different metrics for predicting the extent of resource consumption required. components can be combined. Generally, the PCSs are not The proposed complexity metrics build on the approaches standalone IT systems. These systems are linked to existing IT proposed in Felfernig (2004) and Kristjansdottir et al. (2017) by systems within the companies (e.g., ERP, CAD, PLM, PDM, and ascertaining the cognitive complexity of the UML class diagram calculation systems) either through integrations and/or interfaces. associated with a given configuration problem. The proposed Coupled with the inherent complexity of the product knowledge metric takes into account the effort required to understand and modelled into the system, the integrations to other IT systems will modify the way in which the PCS has been modelled, in terms of render these configuration systems to be highly complex. generalizations and aggregation structures, and the number and the Practitioners in the industry are interested in metrics for type of business rules and attributes present in the configuration comparing different PCS [5] and predicting the resource model. consumption required for developing, maintaining and extending The remainder of the paper is structured as follows. In Section 2 the systems [6], [7]. The approach proposed in [6] defines a load the concept of cognitive complexity known of software systems is 1 introduced. The research methodology employed to carry out the Engineering Management Department, Technical University of Denmark, analysis is explained in Section 3. Section 4 provides an overview email: amgho@dtu.dk, katkr@dtu.dk, lahv@dtu.dk 2 Toulouse University, email: elise.vareilles@mines-albi.fr of the mapping of the cognitive complexity metric of software systems to configuration models. Section 5 then presents the which in turn are made up of the blocks of BCSs, and the findings from applying the method in a case company. Finally, constituent attributes [12]. Therefore, the cognitive complexity of a Section 6 discusses the results and provide guidance for further method comprising q linear blocks of m layers of nesting BCSs studies. with n linear BCSs in each layer, is calculated using the following equation (1): 2 Theoretical Background (1) This section presents the theoretical background for the proposed Where, complexity metric for configuration models. It provides an MC: total cognitive weight of the method overview of the existing literature on the topic of cognitive 𝑀𝑀𝑐𝑐(𝑗𝑗, π‘˜π‘˜, 𝑖𝑖): cognitive weights of individual BCSs complexity of software systems. Cognitive complexity is a measure of the functional complexity Moreover, the attributes of a class are assigned cognitive associated with designing and understanding a software system, weights according to a categorization of the cognitive phenomena based on the basic control structures (BCSs) existing in the system associated with their datatypes [13]. The cognitive weights for the [9]. BCSs are considered to the building blocks of any software attribute categories are summarized in Table 2. The attribute system. They are a collection of fundamental flow control complexity (AC) of a class is calculated by multiplying the number mechanisms which are necessary for constructing the logical of attributes belonging to a particular datatype category and its architecture of a software system [8]. Initially, Hoare et al. [10] corresponding cognitive weight. identified three types of primitive commands (SKIP, ABORT and Assignment) and five types of more complex commands Table 2: Cognitive weights assigned to attributes (Adapted from (sequential composition, non-determinism, conditional, iteration Arockiam and Aloysius [13]) and recursion) in programming languages. Later, two further BCSs Attribute Associated Cognitive Cognitive Weight Datatype Phenomena (function call, interrupt) were identified in system modelling by Wang [11]. Considering the sequential BCS as being representative Primary Sub-concious cognitive 1 of a unit BCS, a different cognitive weight is assigned to each function BCS. The cognitive weight of a BCS is considered to be Derived Meta cognitive function 2 proportional to the effort required by a user in understanding the functionality and the semantics of the BCS, relative to the User-defined Higher cognitive function 3 sequential BCS. Table 1 summarizes the BCSs and the corresponding cognitive weights: Therefore, for a class containing β€˜m’ number of methods, with the i-th method having a complexity of MCi, and having an attribute Table 1: Cognitive weights of basic control structures (Adapted from complexity, AC, equation (2) shows the cognitive complexity of Wang, 2006 [9] the class (CC). Category of BCS BCS Cognitive Weight (2) Sequential Sequence (SEQ) 1 The reusability of software code in object-oriented Branch If-Then- 2 programming languages is facilitated through the concept of Else (I-T-E) inheritance. However, the use of several levels of inheritance Case 3 often has an adverse impact on the maintainability and Iteration For-do 3 comprehensibility of software systems [14], [15]. Therefore, a Repeat-until 3 number of cognitive complexity metrics have been proposed to While-do 3 penalise the use of inheritance structures in OOPs [14], [16]. Embedded Function Call (FC) 2 At the class level, the cognitive complexity of a class, CCi, Recursion (REC) 3 takes into account the number and complexity of the inherited classes, as shown in the following equation (3) [14][17]: Concurrency Parallel (PAR) 4 Interrupt (INT) 4 (3) Where, Existing literature proposes several approaches for calculating : cognitive complexity of the i-th class due to inheritance the cognitive complexity of programs written in object-oriented : cognitive complexity of an inherited class of class i programming languages, based on the cognitive weights of the π‘˜π‘˜: the number of inherited classes of class i BCSs. Object-oriented programs comprise a number of classes, 𝑙𝑙: the number of constituent methods in class i each of which consist of a number of attributes and methods, and : the cognitive complexity of the j-th method of class i are linked to other classes through aggregation, generalization or association structures. The overall complexity of object-oriented Another approach to account for the presence of inheritance programs is obtained by calculating the cognitive complexity of the structures involves changing the way in which the total cognitive constituent classes based on the relationships between the classes. complexity of the program is calculated, depending on the level of The class complexity (CC) is calculated by taking into inheritance of individual classes [16]. In this case, if the classes consideration the cognitive complexity of the individual methods, are on the same level of inheritance, their cognitive complexity values are added together. However, if the classes are children of These parameters are utilized to calculate the cognitive complexity parent classes, then their values are multiplied. This is shown in metric for each configuration model. the following equation (4) : Moreover, the information regarding the development time and maintenance time for both the PCSs were also collected, in order to (4) establish a relation between the cognitive complexity metric and Where, the development time and maintenance time. However, the time 𝑇𝑇C: cognitive complexity of the program registrations for these PCSs are not accurately maintained by the WCC𝑗𝑗𝑗𝑗: cognitive complexity of k-th class at level j of inheritance. company, thereby requiring an assessment of the reliability of the data. After an initial analysis of the data, coupled with discussions The cognitive complexity approach has been applied to with the members of the configuration team at the case company, empirically calculate the complexity of UML class diagrams. The the authors decided to analyse the two PCSs for which the time cognitive complexity of UML class diagrams has been shown to registrations were accurate and reliable. The relation between the be correlated to the generalization and association structures, with development time for the PCSs, the cognitive complexity metrics an increase in the number of classes and attributes leading to an and the unknown time constants were framed in the form of an increase in the cognitive complexity and also the time required to objective function. The objective functions were solved to obtain understand and modify the class diagrams [18]. This implies that, the values for the time constants, by means of linear regression. given the UML class diagram of a configuration model and, consequently, the cognitive complexity of the configuration model, the required man-hours for developing and maintaining 4 Proposed Cognitive Complexity Metric for the PCS can be estimated. In turn, this will make it possible for Configuration Models better resource planning for PCS projects, allowing more accurate As addressed earlier, existing literature proposes a number of business cases to be developed, prior to the initiation of projects. approaches for measuring the cognitive complexity of OOPs. However, the application of this concept to UML class diagrams of product configuration models presents an important deviation from 3 Methodology those pertaining to OOPs. As PCSs are knowledge-based systems, The authors have adopted the case study research method to the complexity of business rules (BRs) have a vital impact on the calculate the complexity of a configuration model and, development and maintenance efforts of these systems [7]. In order subsequently, propose a relation, which expresses the development to account for the impact of the BRs, the authors have assumed that time in terms of the proposed complexity metric. each BR corresponds to a single method with a single block of The case company is a world leader in catalysts and surface layered BCS. Each constituent BCS of a BR has been assigned a science. It offers a variety of catalysts and a complete range of cognitive weight, based on the classification proposed by Wang proprietary equipment, spare parts, and consumables. The company [8]. Table 3 summarises the cognitive weights for BCSs for each first launched a PCS in 2013 and has since then been building up BR. the configuration area at the company. Currently the company uses five PCSs in the company, while two configurators are under Table 3: Cognitive weight of BCS for BR development. The PCSs used by the company support the sales Category of BCS BCS Cognitive Weight process of both catalysts and equipment at the company and where Assignment Assignment (ASS) 1 the first PCS supporting the engineering process, or the detail design of an equipment is being tested. The complexity of the Branch If-Then-Else (I-TE) 2 PCSs used at the company has quite variations but the lack of or implication method for analysing the complexity makes it difficult both to Iteration Iteration 3 predict maintenance effort for the different PCS in utilization at the Embedded User Function Call 2 company and development effort required for new PCS. Thus, the (UFC) company’s challenges were aligned with the research focus of the Standard Function 1 article. Call (SFC) In this study, the authors have analysed the configuration models pertaining to two PCSs. For each PCS, the following Thus, the cognitive complexity of a BR (BRC), consisting of m dataset was extracted from the configuration platform and used in layers of nesting BCSs with nj linear BCSs in each layer, can be the analysis: calculated using the following equation (5): β€’ Model properties and statistics (5) o Number of business rules Where, o Number of attributes 𝑀𝑀𝑐𝑐(𝑗𝑗, 𝑖𝑖): cognitive weight of the i-th BCS in the j-th layer of a o Number of classes nesting BCS pertaining to a BR. β€’ Documentation of the configuration model nj: number of BCS in the j-th layer of a nesting BCS pertaining to o Class structure a BR o The attributes and their domains for each class o The business rules for each class Another feature of UML class diagrams specific to configuration models is the cardinality of the classes representing the aggregation structure. This particular feature is accounted for by the presence of the iteration BCS. A nested BR containing an In case of the class Frame in Figure 1, the calculation for the iteration BCS would only be invoked in cases wherein more than a attribute complexity is shown below in Table 5. single instance of a particular class is required to be created. As mentioned earlier, the cognitive complexity of a class also Table 5: Descriptive example of bicycle: Calculation of attribute comprises the cognitive complexity of the attributes. Table 4 shows complexity the possible attribute domains present in the configuration platform Attribute Domain Datatype Cognitive Attribute used at the case company categorised according to the datatype Name category Weight Complexity categories mentioned in Table 2. (AC) Size Integer Primary 1 Table 4: Cognitive Weights of Attribute Datatypes Material Named Derived 2 1+2 = 3 Datatype Category Attribute Domain Cognitive Weight Domain Primary Integer, Float, 1 For calculating the BRC for the class Frame, the nature of the BRs Boolean are established and the component BCSs are assigned their Derived Named Domain 2 cognitive weights based on the categorization of BCSs. User-defined Function, Class 3 BR_1 comprises of a single layer of nesting BCS (if statement) consisting of a single assignment BCS within it. Therefore, the BRCBR_1 is calculated using equation (5) as shown below: Therefore, given a configuration model, the cognitive complexity of a constituent class (CCi), comprising β€˜m’ methods, BRCBR_1 = (Cognitive weight of if statement) * (Cognitive weight β€˜n’ attributes and β€˜p’ business rules, is calculated by adding the of assignment statement) cognitive complexities of the methods (MCj), attributes (AC) and BRCBR_1 = 2*1 = 2 the business rules (BRCk), as shown in equation (6): BR_2, on the other hand, is categorized as a standard function in (6) the PCS software which has been used to model the configuration problem. Therefore, the business rule complexity of BR_2, However, as the source codes of the configuration platforms BRCBR_2, is assigned the cognitive weight of 1. Therefore, the (such as Tacton, Configit, SAP Configurator and so on) are cognitive complexity of the class Frame, CCFrame, is calculated as generally confidential in nature and not available publicly, the shown below, according to the equation (7). authors decided to consider only the attribute complexity and the complexity of the business rules. Therefore, the final form of the CCFrame = ACFrame + (BRCBR_1 + BRCBR_2) = 3+(2+1) = 6 cognitive complexity metric for a class used in the analysis is shown in equation (7). Table 6 summarizes the results for the remainder of the classes shown in Figure 1. (7) Table 6: Descriptive example of bicycle: Calculation of class complexity As an example to illustrate the various calculations, an excerpt Class Name BRC AC CC of an UML class diagram, depicting the configuration model Frame 3 3 6 pertaining to a bicycle, is presented in Figure 1. The model Suspension 0 3 3 comprises three classes (class Frame, class Suspension and class Fork 1 4 5 Fork). The model comprises two aggregation relationships (wherein class Suspension and class Fork are β€œparts of” the class Frame) but no inheritance structures. The corresponding Depending on the inheritance structure, the total complexity of cardinalities, attributes and business rules are also shown in the the configuration model (TC) can be calculated by a combination figure. of the cognitive complexities of the constituent classes, as shown in equation (8). (8) Where, CC𝑗𝑗𝑗𝑗: cognitive complexity of the k-th class at the j-th level of inheritance. Therefore, the total complexity of the configuration model shown in Figure 1 is given by: TC = 6+3+5 = 14. Given the value of the total cognitive complexity metric, TC, for a particular configuration model, the authors propose a relation, as shown by equation (9), to estimate the development time (XTime) and the maintenance time for the model in man-hours. Figure 1: Descriptive example of bicycle 𝑋𝑋𝑇𝑇𝑇𝑇𝑇𝑇e = π‘Žπ‘Ž + 𝑏𝑏. 𝑇𝑇C (9) Where, Table 8: Additional metrics representing the complexity of the π‘Žπ‘Ž: development time constant (in man-hours) PCS 𝑏𝑏: development time constant (in man-hours) associated with a Model ACavg BRavg CCavg configuration model having a cognitive complexity of 1. PCS_1 2.24 6.87 118.67 PCS_2 1.71 4.08 60.63 Taking into consideration the development times and the Overall average for any PCS 1.97 5.48 89.65 cognitive complexities of the two configuration models for which the time registration is available and accurate, the values of the The values for ACavg and BRavg for each of the models do not take time constants, a and b, are calculated, using linear regression. into consideration the class structure for the configuration models. However, as the value of TC is often not readily available Based on these three metrics, the estimated average attribute before a configuration model has been fully developed, an complexity, average business rule complexity and average class estimated development time, 𝑋𝑋𝑋𝑋𝑋𝑋, can be calculated for a complexity values for a configuration model developed at the case particular configuration model if the number of constraints and the company are 1.97, 5.48 and 89.65 respectively. However, the number of attributes, as shown in equation (10), or the number of results also show that there is a great variation of the complexity classes, as shown in equation (11), are known. metrics calculated for the two systems, thus, the average complexity might not be provide us with the best possible estimates 𝑋𝑋𝐸𝐸𝐸𝐸 = π‘Žπ‘Ž + 𝑏𝑏. ({#π‘Žπ‘Žttribute. ACπ‘Žπ‘Žv + #BR. BRCπ‘Žπ‘Žv}) (10) for the complexity of configuration models at the case company. Moving forward, more PCSs at the case company will have to be 𝑋𝑋𝐸𝐸𝐸𝐸 = π‘Žπ‘Ž + 𝑏𝑏. (#class. CCπ‘Žπ‘Žvg) (11) analysed to obtain results that are more indicative of the average The following section presents the results obtained from the PCS complexity at the company. application of the proposed metrics on two configuration models at For the calculation of the time constants, a and b, pertaining to the case company. the relation between the cognitive complexity of the two configuration models and the development time for the corresponding PCSs, as expressed in Equation (9), the development 5 Results from the Case Study times (in man-hours) are noted in Table 9. As explained earlier, the authors have only considered two PCSs, Table 9: Development time in man-hours for the analysed PCS in the case for which reliable and accurate time registration data was available, company for their analysis. To calculate the cognitive complexity metric of Model Development Time (in man-hours) the corresponding configuration models, the following data was PCS_1 2219 extracted from the configuration platform used at the case PCS_2 380 company: Therefore, given the value of the total cognitive complexity of a β€’ The UML class diagrams configuration model, TC, the estimated development time of a PCS β€’ The attributes and their datatypes for each class at the case company can be calculated as: β€’ The business rules associated with each class β€’ Statistics pertaining to the overall configuration model: 𝑋𝑋𝑇𝑇𝑇𝑇𝑇𝑇e = 8.065 + 0.227𝑇𝑇C (12) o Number of classes in the UML class diagram o Total number of attributes in the UML class diagram The ACavg, BRCavg and CCavg are obtained from the data for the o Total number of constraints in the UML class diagram PCSs that have been analysed in this paper. Therefore, the final form of the equations (10) and (11) to estimate the development Based on this data, the total complexity, TC, of the two PCSs time of PCSs in man-hours at the case company, given the were calculated. The results, along with the input data are expected number of attributes and business rules or the expected summarised in Table 7. number of classes, are presented in equations (13) and (14) Table 7: Complexity calculations and statistics for the two PCSs analysed respectively: Parametric Cognitive Model #Classes #Attributes #Rules complexity complexity 𝑋𝑋𝐸𝐸𝐸𝐸 = 8.065 + 0.227({#attribute Γ— (1.97) + #BR Γ— (5.48)}) (13) PCS_1 82 1462 940 2402 9731 𝑋𝑋𝐸𝐸𝐸𝐸 = 8.065 + 0.227({#𝑐𝑐lass Γ— (89.65)}) (14) PCS_2 27 334 262 596 1637 Therefore, the following parameters of the configuration model are the pre-requisites for calculating an estimated development Table 5 shows considerable differences in both the parametric time for the PCS: and the total cognitive complexities (TC) of the analysed PCSs. This result is aligned with the initial scoping of the research of β€’ The estimated number of classes, or selecting PCSs representing both high complexity values and low β€’ The estimated number of business rules and attributes. complexity values. Moreover, three additional metrics were also defined for each model, as shown in Table 8. These metrics include Moreover, based on the hours used for development the required the average values of the attribute complexity (ACavg), business hours for maintenance can be calculated. Based on interviews in rule complexity (BRCavg) and the class complexity (CCavg). the company it is estimated that 30% of the total development hours are required on a yearly base for the maintenance activities. 6 Discussions and Conclusions This study focuses on the complexity of the configuration model. This means that the complexity resulting from integrations This paper proposes a metric for evaluating the complexity of a to other IT systems are not considered. Also, complexity for PCS, by taking into the consideration the UML class diagram of generating user interfaces and output documents are not taken into the corresponding configuration model. The proposed cognitive the account in the present study. Future work will, therefore, focus complexity metric takes into the account the effort required to on including these parameters to better capture the overall understand and modify the way in which the configuration problem complexity associated with a PCS and not only the complexity of has been modelled. Furthermore, the authors also investigate the the configuration model. relation between the effort in man-hours required for the development of a new PCS and the proposed complexity metric. The results obtained in the present article aim to contribute to7 the REFERENCES field of PCS complexity and the impact of PCS complexity on the effort estimation associated with the development and maintenance [1] C. Forza and F. Salvador, β€œManaging for variety in the of PCS projects. order acquisition and fulfilment process: The contribution The proposed metric for calculating the cognitive complexity of of product configuration systems,” Int. J. a configuration model builds on research in the fields of the Prod. Econ., vol. 76, no. 1, pp. 87–98, 2002. cognitive complexity of object-oriented software systems [8], [9], [2] S. Mittal and F. Frayman, β€œTowards a generic model of configuration tasks,” Proc. Elev. Int. Jt. Conf. Artif. Intell., [12], [13], complexity of PCS [5]–[7] and the cognitive complexity vol. 2, pp. 1395–1401, 1989. of UML diagrams [18]. The presence of business rules and a lack [3] A. Felfernig, G. E. Friedrich, and D. Jannach, β€œUML as of material on the source codes of commercial configuration domain specific language for the construction of platforms render the direct application of existing cognitive knowledge-based configuration systems,” Int. J. Softw. complexity metrics to configuration models unviable. Eng. Knowl. Eng., vol. 10, no. 4, pp. 449–469, 2000. By having a more standardized way of analysing the complexity [4] K. R. Ladeby and J. L. Pedersen, β€œApplying Product of a configuration model should enable both more accurate Configuration Systems in Engineering Companies : resource estimations and allow for a comparison of different Motivations and Barriers for Configuration Projects,” configuration models. The authors adopted a structured approach to DTU, 2009. analyze the cognitive complexity of a configuration model and [5] K. Kristjansdottir, S. Shafiee, L. Battistello, L. Hvam, and relating it to the development and maintenance efforts. First, an C. Forza, β€œComplexity of Configurators Relative to UML class diagram is analysed, which should give information Integrations and Field of Application,” 19th Int. Config. regarding total complexity of a configuration model (based on Work., 2017. number of classes, the number and type of attributes, number and [6] M. Aldanondo and G. Moynard, β€œDeployment of type of business rules). Second, the average values of the attribute Configurator in Industry: Towards a Load Estimation,” complexity (ACavg), business rule complexity (BRCavg) and the ECAI 2002 Work. Config., pp. 125–130, 2002. class complexity (CCavg) are calculated. Third, linear regression is [7] A. Felfernig, β€œEffort Estimation for Knowledge-based used to analyse man-hours for already developed systems to predict Configuration Systems.,” SEKE, pp. 148–154, 2004. the future workload for new PCS. [8] Y. Wang, β€œCognitive Complexity of Software and its The proposed method is validated in a case company where two Measurement,” Proc. 5th IEEE Int. Conf. Cogn. different PCS were selected. The two PCS represent both PCSs Informatics, vol. 1, pp. 226–235, 2006. with high and low parametric complexity. The proposed metric for [9] J. Shao and Y. Wang, β€œA new measure of software analysing the cognitive complexity of the PCS confirmed the complexity based on cognitive weights,” in Canadian variation in the complexity. Further, by analysing the man-hours Conference on Electrical and Computer Engineering, used for developing the systems, a function of total complexity and 2003, vol. 2, pp. 1333–1338. man-hours is used to predict the workload for a new PCS. The [10] C. A. R. Hoare et al., β€œLaws of programming,” Commun. testing of the proposed method confirmed its usability. Further, ACM, vol. 30, no. 8, pp. 672–686, Aug. 1987. testing is planned with in the case company where all the PCSs will [11] Y. Wang, β€œThe Real-Time Process Algebra (RTPA),” be analysed in more detail, in order to verify the accuracy of the Ann. Softw. Eng., vol. 14, no. 1–4, pp. 235–274, 2002. estimated development effort in man-hours when starting new PCS [12] S. Misra, M. Koyuncu, M. Crasso, C. Mateos, and A. projects. Zunino, β€œA Suite of Cognitive Complexity Metrics,” in There are a few limitations to the research presented in this International Conference on Computational Science and article. The proposed cognitive complexity metric primarily Its Applications -2012, 2012, pp. 234–247. addresses only those configuration models which can be presented [13] L. Arockiam and A. Aloysius, β€œAttribute Weighted in form of an UML diagram. Further research will have to Class Complexity : A New Metric for Measuring conducted in order to investigate the viability of applying cognitive Cognitive Complexity of OO Systems,” World Acad. complexity concepts to declaratively modeled products. Moreover, Sci. Eng. Technol. Int. J. Comput. Electr. Autom. in case of declarative BRs, the authors have used their discretion to Control Inf. Eng., vol. 5, no. 10, pp. 1151–1156, 2011. assign cognitive weights to such BRs. In certain cases, the [14] D. Mishra and A. Mishra, β€œObject-oriented inheritance procedural equivalent of the declarative BR is assigned the metrics in the context of cognitive complexity,” Fundam. Informaticae, vol. 111, no. 1, pp. 91–117, 2011. corresponding cognitive weight, whilst in others, the authors have [15] R. Harrison, S. Counsell, and R. Nithi, β€œExperimental considered the declarative BR to be either a standard function of assessment of the effect of inheritance on the the PCS or a user defined function. maintainability of object-oriented systems,” J. Syst. Softw., vol. 52, no. 2–3, pp. 173–179, 2000. [16] S. Misra, M. Koyuncu, M. Crasso, C. Mateos, and A. Zunino, β€œA Suite of Cognitive Complexity Metrics,” Int. Conf. Comput. Sci. Its Appl. - ICCSA 2012, vol. 7336, pp. 234–247, 2012. [17] H. Li, β€œDynamic analysis of Object-Oriented software complexity,” 2012 2nd Int. Conf. Consum. Electron. Commun. Networks, CECNet 2012 - Proc., pp. 1791– 1794, 2012. [18] M. Esperanza Manso, J. A. Cruz-Lemus, M. Genero, and M. Piattini, β€œEmpirical Validation of Measures for UML Class Diagrams: A Meta-Analysis Study,” LNCS, vol. 5421, pp. 303–313, 2009.