Using Software Requirement Specification as Complexity Metric for Multi-Paradigm Programming Languages

Transcription

1 Using Software Requirement Specification as Complexity Metric for Multi-Paradigm Programming Languages Olabiyisi S.O. 1, Adetunji A.B 2, Olusi T.R 3 1,2 Department of Computer Science and Engineering, Faculty of Engineering and Technology, Ladoke Akintola University of Technology, Ogbomoso, Oyo State, Nigeria. 3 Department of Computer Science, Institute of Basic and Applied Sciences, Kwara State Polytechnic, Ilorin, Nigeria. Abstract--The existing complexity metrics being used are based on code and cognitive metrics. This study therefore proposed a complexity metric using Software Requirement Based Specification. The proposed approach identified complexity of software immediately after freezing the requirement in Software Development Life Cycle (SDLC) process. In order to develop a metric, this research took the IEEE Software Requirement Specification (SRS) document as a basis. Proper analysis of each and every component of SRS document of complexity metrics was considered. Functional and Non- functional requirements were also employed to develop an improved complexity metric. In order to validate the proposed metric, it was then applied on ten (1) different sorting algorithms written in C++ language and further compared with other established code based metrics. The metric compares well with other established complexity metrics and can be used to estimate complexity of proposed software much before the actual implementation of design thus saving cost, time and manpower wastage. Keywords-- Design Constraints Imposed Functional Requirement, Input and Output Complexity, Interface Complexity, Non Functional Requirement, Requirement Base Complexity, System Feature Complexity, User / Location Complexity. I. INTRODUCTION A wide range of activity is associated with different phases of software development. Software metrics are techniques/formulas to measure some specific property or characteristics of software. In software engineering, the term 'software metrics' is directly related to the measurement. Software measurement has significant role in the software management. According to DeMarco (1986) "You can't manage what you can't measure!" Campbell also emphasized the importance of measurement by stating that If you aren t measuring you aren t managing you re only along for the ride (downhill)!. At this point it is worth to define 'measurement' itself. Norman Fenton (1992) defines measurement as the process by which numbers or symbols are assigned to attributes of entities in the real world in such a way as to describe them according to clearly defined rules. 562 Software metrics are quantitative guide to the performance of a certain piece of software in relation to the human interaction needed to make the software work. Metrics have been established under the idea that before something can be measured or quantified, it needs to be translated into numbers for easy understanding, coding and evaluating the quality of the program. There are several areas where software metrics are found to be of use. These areas include everything from software planning to the steps that are meant to improve the performance of certain software. Software cannot perform on its own without human interaction. Therefore, in a way, software metric is also a measure of a person's relation to the software that he or she is handling. Software systems are complex therefore, it is hard to attain a high level of quality. Software metrics have always been an important tool and it was realized that software development is a complex task. Due to its complexity, software quality been a rising demand for decades and some definitions have been manifested throughout software history. A software product should carry several quality attributes, such as correctness, reliability, efficiency, integrity, usability, maintainability, testability, flexibility, portability, reusability and interoperability. According to Somerville (24), the most necessary software quality attribute is maintainability. To efficiently be able to maintain a software system, the codes should be understandable for developers. Briefly, to achieve high quality, reduction of complexity is 'essential. To deal with software complexity, software metrics are used. Metrics are indicators of complexity; they expose several weaknesses of a complex software system. Therefore, by the means of software metrics, quality can be estimated. That is why metrics take an indispensable role in software development life cycle. Software complexity metrics are used to quantify a variety of software properties. Usually, it is extremely hard to build high quality software or improve the development process without using any metrics. There are a number of metrics each focusing on different complexity factors. Large companies such as Hewlett-Packard, AT&T, and Nokia use several metrics to estimate the quality of their software systems.

2 McCabe et al. (1976) defined software complexity as "one branch of software metrics that is focused on direct measurement of software attributes, as opposed to indirect software measures such as project milestone status and reported system failures." Basili (198) defined complexity as a measure of resources used by a software system during the interaction of the parts of the software, to perform a task. If the interacting entity is a computer, then complexity is related to the execution time and hardware resources required to perform the task. If the interacting entity is a programmer, then complexity is related to the difficulty of coding, testing and modifying the software. It is believed that for coding and modifying a software system, a higher comprehensibility of the code is required. If the comprehensibility is higher, then the complexity of the software is lower, and thus testing is easier. Somerville (24) categorizes metrics as control and predictor metrics. The various popular metrics complexity measures are under several criticisms. These criticisms are mainly based on lacking in desirable measurement properties, being too labour- intensive to collect and only confined to the features of procedural languages most of the available metrics cover only certain features of a language. For example, if line of code is applied then only size will be considered. If McCabe complexity is applied the control flow of the program will be covered. Moreover, most of the available metrics do not consider the cognitive characteristics in calculating the complexity of a code, which directly affects the cognitive complexity. If a code has a low cognitive complexity, programmer can easily grasp the code without wasting too much time. High cognitive complexity indicates poor design which sometimes can be unchangeable. Hence, there is a need to propose a new complexity measure that is able to estimate software complexity in early phases of software life cycle, even before analysis and design is carried out. This research work is to develop a Software Requirement Specification (SRS) based complexity metric for multi paradigm programming languages. II. REVIEW OF RELATED WORK Many well known software complexity measures have been proposed such as McCabe cyclomatic complexity, Line Of Code and Halstead complexity metric. All the reported complexity measures are supposed to cover the correctness, effectiveness and clarity of software and to provide good estimate of these parameters. Out of the proposed measures, selecting a particular complexity measure is again a problem as every measure has its own advantages and disadvantages. 563 In this research work the proposed complexity metric was developed using requirement based complexity measure and its performance is compared with the existing metrics such as line of code, Halstead complexity measure and Cyclomatic complexity. Cyclomatic Complexity Cyclomatic Complexity formula is given below: m =e-n +2 p (1) Where, m is the cyclomatic complexity e is the number of edges n is the number of vertices p is the connected components Halstead Complexity Measure Maurice Halstead proposed this measure which is based on the principle of Count of Operators and Operand and their respective occurrences in the code. These operators and operands are to be considered for the formation of Length and Vocabulary of Program. Further Program Length and Vocabulary serve as basis for finding out Volume, Potential Volume, Estimated Program length, Difficulty and finally effort and time by using following formulae. Program Vocabulary, n = n1+n2 Program Length, N = N1+ N2 Volume, V= N*log2n Estimated Program Length N^ = n1 log2 n1 + n2 log2 n2 Potential Volume, V* =(2+n2*)log2(2+n2*) Program Level, L = V*/V Effort, E =V/L in elementary mental discriminations Reasonable Time, T = E/B min Difficulty = 1/language level Lines of Code This metric considers the number of lines of code inside a program. It has some types (Resource Standard Metric, 21): - Lines of Code (LOC): counts every line including comments and blank lines. - Kilo Lines of Code (KLOC): it is LOC divided by 1. - Effective Lines of Code (eloc): estimates effective line of code excluding parenthesis, blanks and comments. - Logical Lines of Code (LLOC): estimates only the lines which form statements of a code.

3 III. MATERIAL AND METHODS This metric is based on the factors derived from software requirement specification (SRS) document. The calculations for this metric base on different parameters are specified below. A. Complexity Attribute 1: Input-Output Complexity (IOC) This complexity refers to the input and output of the software system and attached interfaces and files. Following four attributes are considered: Input: As Information entering to the System Output: Information Leaving System Interface: User Interface where the Input are to be issued and output to be seen and specifically number of integration required Files: This refers to the data storage required during transformation Input Output Complexity can be defined as: IOC = Number of Input variable + Number of Output + Number of Interfaces + Number of files (1) B. Complexity Attribute 2: Functional Requirement (FR) Functional Requirement defines the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating outputs. Functionality refers to what system is supposed to do. This describes the general factor that affects the product and its functionality. Every stated requirement should be externally perceivable by users, operators or other external systems. It may be appropriate to partition the functional requirement into sub-functions or sub-processes FR = No. of Functions * (2) Where SPF is Sub-Process or Sub-Functions received after decomposition. C. Complexity Attribute 3: Non Functional Requirement (NFR) This refers to the Quality related requirements for the software apart from functionality. These requirements are categorized into THREE categories with their associated precedence values as shown in Table 1. As high the precedence that much high will be the value, which will further depend upon the count. It can be mathematically described as: NFR = (3) 564 Table I Describes the different types of Non Functional Requirement Type Count Optional Req 1 Must be Type 2 Very important Type 3 D. Complexity Attribute 4: Requirement Complexity (RC) It refers to the sum of all requirements i.e. Functional Requirement (FR) and its decomposition into sub-functions and Non Functional Requirements: RC = FR * NFR (4) E. Complexity Attribute 5: Product Complexity (PC) This refers to the overall complexity based on its functionality of the system. We have proposed this a product of Requirement Complexity (RC) and Input Output Complexity (IOC). It can be mathematically described as: PC = IOC * RC (5) F. Complexity Attribute 6: Personal Complexity Attributes (PCA) For effective development of software, Technical Expertise plays a very significant role. Now computation of the Personal Attributes lead to technical expertise, and this is referred to as the Multiplier Values for Effort Calculation i.e. Cost Driver Attributes of Personal Category from COCOMO Intermediate model proposed by Berry Boehm and they are shown as follows Table II Cost Driver Attributes and their values used in COCOMO Model Attribute Rating Very low Low Normal High Very high Analysis Capability Application Expertise Programming Capability Virtual Machine Expertise Programming language Expertise Mathematically PCA can be described as Sum of Product of attributes as shown in the table above. PCA= (6) Where MF are the Multiplying Factor

4 G. Complexity Attribute 7: Design Constraints Imposed (DCI) It refers to no. of constraints that are to be considered during development of software/ system by any statuary body/ agencies which includes number of regulatory constraints, hardware constraints, communication constraints, database constraints etc. This metrics can be mathematically defined as. DCI = (7) Where Ci is Number of Constraints and value of Ci will vary from to n. Ci = { {value H. Complexity Attribute 8: Interface Complexity (IC) if Blind Development if Constraint exists This complexity attribute is used to define number of External Integration/Interfaces to the proposed module/ program/ system. These interfaces can be hardware interface, communication interface and software interface etc. IFC = (8) Where EIi is Number of External Interfaces and value of EIi will vary from to n IFC= { if no external interface {value if Constraint exists I. Complexity Attribute 9: Users/ Location Complexity (ULC) This measure refers to the number of user for accessing the system and locations (Single or Multiple) on which the system is to be deployed/ used ULC= No. of User * No. of Location (9) J. Complexity Attribute 1: System Feature Complexity (SFC) This refers to the specific features to be added to the system so as to enhance the look and feel feature of the system SFC = (Feature1 * Feature2 *. * Feature n) (1) Complexity Definition: Requirement Based Complexity Finally the Requirement Based Complexity () can be obtained by considering all above definitions. It can be mathematically shown as: = ((PC * PCA) + DCI + IFC + SFC) * ULC (11) The Requirement Based Complexity will be higher for the programs, which have higher Functionality to be performed and more quality attributes which is to be retained. All above measure were illustrated with the programs that were developed. IV. IMPLEMENTATION AND RESULTS For illustration of Requirement Based complexity (), 1 different programs were selected and developed. These programs are different from each other in their architecture, the calculation of for sample of the program is given in figure as specified below: void bubblesort(int numbers[], int array_size) { } int i, j, temp; for (i = (array_size - 1); i >= ; i--) { } for (j = 1; j <= i; j++) { } if (numbers[j-1] > numbers[j]) { } temp = numbers[j-1]; numbers[j-1] = numbers[j]; numbers[j] = temp; Figure I. Program 565

5 Analysis Of Program 1. Input Output Complexity (IOC) Number of Input = Number of Output = Number of Interface = 1 Number of files = 1 IOC = Number of input + number of output + Number of Interface + Number of Files = ++1+1=2 2. Function Requirement (FR) Number of functional Req = 1 () Number of Sub- Processes = 2 (Increment, Decrement) FR = Number of FR *Number of SP FR= 1*2 = 2 TABLE III Requirement Based Complexity () PROGRAMS 2.34 Bubble sort Bucket sort Non Functional Requirement (NFR) Number of NFR = 4. Requirement Complexity (RC) RC= FR + NFR RC= 2 + =2 5. Product Complexity (PC) PC = IOC * RC PC = 2 * 2 =4 6. Personal Complexity Attribute (PCA) PCA = MF3 PCA = Design Constraints Imposed (DCI) Num of constraints = 8. Interface Complexity (IFC) IFC = 9. User/Location Complexity (ULC) ULC = Num of user * Num of location ULC = 1* 1 =1 1. System Feature Complexity (SFC) SFC = = ((PC * PCA) + DCI +IFC + SFC) * ULC (4 * 1.17) *1 = Counting sort 51.8 This section of the research work analyses the result of applying on 1 programs selected and developed on a C++ language so as to find the complexity variation in terms of code. In order to analyze the validity of the result, the for different program was calculate based on software Requirement specification (SRS) and further compared with other established measures which are summarized in above Table. Table 3 contains the statistics that are collected after analyzing the C++ codes to evaluate the measures. The empirical validation is in two folds. First the code based complexity measures such as effective Line Of Code (eloc), Cyclomatic Complexity (CC) and Volume, Effort Difficulty and Time estimations from Maurice Halstead metrics are all applied. Secondly, the statistics that are collected from these metrics is compared with the values obtained from to investigate the usefulness and effectiveness of the proposal. V. ANALYSIS OF RESULT Counting sort program with of 51.8 was discovered to be the most complex program among the ten (1) programs when using measure. 566

6 In eloc of 38 CC of 1 and volume of 642 in Radix sort program is observed to be more difficult to grasp than others. Effort with value 2295 and Time with value 1275 shows that program is the most complex. Selection sort program with of 2.34 has a less Requirement Based complexity than the bubble sort program of 4.68 due to its readability. The bubble sort program required more though process, although selection sort program has more line of code. Similarly, CC and Maurice Halstead metric are able to show this too. Shell sort program is more than insertion sort program. It shows that it is more difficult to grasp than insertion sort program, however eloc CC and Halstead result could not measure the differences. Heap sort program and Quick sort program have the same value of 11.1 this is also shows in CC but there is slight difference in eloc. Also, Merge sort program and Radix sort program also have the same of 37. but have differences in eloc Maurice Halsted and CC measure. Radix sort program and in Merge sort program are more complex than Bucket sort program has shown in measure. There is a slight difference CC of merge sort program and Bucket sort program. But in eloc and Halstead there is a significant difference between Bucket sort program and Radix sort program. In comparison with other measure is closer to human understanding. From the above shown result, performs better than other measures in reflecting the comparative complexities, which means will aid the developer and practitioner in evaluating the software complexity in the early phases of software development Table IV Comparison of metrics HALSTEAD Programs eloc CC V D E T eloc Figure II Graph of comparison between eloc and 567

7 Figure IIIComparison between CC and CC Figure V Relative Graph between eloc, and Volume eloc V Figure IV Relative Graph between eloc, CC and eloc CC Figure VI Relative Graph Between CC, and Difficulty VI. 5. CONCLUSION The research work has developed the requirement Based Complexity () measure that is based on software Requirement specification document. CC D 568

8 It is a robust metric because it encompasses all major parameters and attributes that are required to fund out complexity. Further they are comparable with code based complexity measures. On comparing the requirement based complexity measure with rest of the established measure following are the findings: i. follows code based measures which have been computed on the basis of program by identifying number of operators and operands and further vocabulary, Length and finally it is aligned with the difficulty metrics given Maurice Halstead. ii. is more sensitive than other measures which will aid the program developer and practitioner in evaluating the software complexity in early phases of software planning. iii. CC was not able to make sensitive measurement most of the similar code had the same CC values. was able to handle sensitive measurement. REFERENCES [1 ] Ashish Sharma, D.S. Kushwaha 21 A Complexity measure base on requirement engineering document. Journal of Computer Science and Engineering, vol.1. [2 ] Banker, R.D., Datar, S.M., Zweig, D 1989 Software Complexity and Maintainability CiteSeer Scientific Literature Digital Library and Search Engine. [3 ] Basci, D., Misra, S 29 Data Complexity Metrics for Web- Services Advances in Electrical and Computer Engineering, Volume 9, Number 2, 29, pp Basci, D., Misra, S. Measuring and Evaluating a Design Complexity Metric for XML Schema Documents Code. Journal of Information Science and Engineering. pp [4 ] DeMarco, T Controlling Software Projects, Yourdon Press, New York. [5 ] Fenton N. E., Pfleeger, S. L Software Metrics: A Rigorous and Practical Approach, 2nd Edition Revised ed. Boston: PWS Publishing. [6 ] Fenton 1992 N.E. Fenton, Software Metrics A Rigorous Approach, Chapman & Hall, London. [7 ] Halstead, M.H Elements of Software Science. New York: Elsevier North-Holland. [8 ] Halstead 1977 Halstead, M.H. Elements of Software Science, Elsevier North- Holland, New York. [9 ] " &oldid= [1 ] IEEE Computer Society 1998 Standard for Software Quality Metrics Methodology. Revision IEEE Standard 161. [11 ] Ierusalimschy, R. 21 Programming with Multiple Paradigms in Lua Available at: [12 ] Kushwaha, D.S., Misra, A.K. 26 Improved Cognitive Information Complexity Measure: A Metric that Establishes Program Comprehension Effort, Software Enginering Notes, vol 31, no 5. [13 ] LangPop Programming Language Popularity 21 Available at [14 ] Marco, L.: Measuring Software Complexity 21 Available at: [15 ] Martin, S A Critique of Cyclomatic Complexity as a Software Metric. IEEE Software Engineering Journal. [16 ] McCabe, T.J A Complexity Measure. IEEE Transactions Software Engineering. 2(6): p [17 ] McCabe, T.J., Watson, A.H. 21 Software Complexity, McCabe and Associates, Inc. (last accessed ) Available at: Metrics (last accessed ) Available at: [18 ] McCabe 1976 T. McCabe, A complexity measure, IEEE Transactions of Software Engineering, Vol. SE-1, [19 ] Misra, S., Akman, I. 28 A Complexity Metric based on Cognitive Informatics, Lecture Notes in Computer Science, Vol. 59, pp [2 ] Misra, S., Akman, I. 28 A Model for Measuring Cognitive Complexity of Software, Springer-Verlag Berlin Heidelberg pp [21 ] Misra S., Akman, I. 21 Unified Complexity Metric: A measure of Complexity, Proc. Of National Academy of Sciences Section A. [22 ] Misra, S., Akman, I. 28 Weighted Class Complexity: A Measure of Complexity for Object Oriented Systems, Journal of Information Science and Engineering, Vol.24, pp [23 ] Pfleeger, S.L., Atlee, J.M. 26 Software Engineering Theory and Practice, 3 rd International Edition, Prentice Hall, [24 ] Pressman Roger S, 25 Software Engineering -A Practitioner Approach, 4th Edition. [25 ] Ramamoorthy C.V. Ramamoorthy, W-T. Tsai, T. Yamura 1985 A. Bhide Metrics guided methodology, COMPSAC 85, pp [26 ] Roger S. P. 25 Software Engineering A practitioner s approach, 6th Edition. McGraw-Hill. [27 ] Software Quality Assurance (last accessed ) Available at: [28 ] Software Technology Support Centre Software Estimation, Measurement, and Metrics (last accessed ) Available at: [29 ] Sommerville, I. 24 Software Engineering, 7th Edition, Addison Wesley. [3 ] TIOBE Software 21 The Coding Standards Company. Programming Community Index for (last accessed ). Available at: [31 ] Tourlakis, G.J Computability, Reston, Virginia. [32 ] Westbrook, D.S A Multi-paradigm Language Approach to Teaching Principles of Programming Languages, 29th ASE/IEEE Frontiers in Education Conference, San Juan. [33 ] Weyuker, E Evaluating Software Complexity Measures. IEEE Transactions on Software Engineering, vol. 14, W3Schools. [34 ] Zuse H Software Complexity, de Gruiter,Berlin