Measurement, Analysis with Visualization for Better Reliability

Transcription

1 Measurement, Analysis with Visualization for Better Reliability Zeeshan Ahmed and Saman Majeed Department of Bioinformatics, Biocenter University of Wuerzburg, Germany

2 1 Introduction Software industry is growing day by day along with the high expectations of the customers for the high quality products within shortest possible (software engineering) time, low budget and with the use of less man power and resources (Ahmed, 2007). Yet the problem of maintaining high success rate of quality software production in the industry is still there. In the beginning of software engineering, the products were developed using traditional product engineering concepts. For every new product a new design was implemented because there was no such concept of Reusability. With the passage of time software products started expanding and becoming larger in size (line of source code) which in return raised the levels of complexities in production processes. This increase in size and complexity brought a high negative impact on software productivity, effort and scheduling. To cope with the challenge of resolving levels of complexities, researchers started considering Product Line engineering concept, known from the manufacturing industry, which might be adopted to improve the quality during software development processes (Ahmed, 2011). Software product line (see section 2 for details) provided a way to develop high quality products at lower cost, in less time and with the use of limited number of resources. At the same time when it was becoming popular amongst the software engineering communities it also introduced an additional level of complexity that may reduce or eliminate potential productivity gains due to the production of feature interaction and composition problems (Robak and Franczyk, 2001). In product line engineering, multiple sub-products have to be developed and integrated with each other. Managing the process of integration of products is one of the most complex tasks. Software practitioners have little support to cope with this additional level of complexity and gain maximum benefit out of it. Some researchers explicitly claimed of some solutions to these problems but those were not proved though promising when adopted. Meeting the targeted goals of this research, we discuss an approach to analyze, measure and visualize software product artifacts including preprocessed source code characteristics, to support software practitioners with a reliable, effective and efficient software project management solution. We tried to prove that the statistical measurement and quantitative management based approach can be helpful in improving the process of decision making at both strategic and implementation levels. Going into the details of this chapter, we present traditional and product line software architectures, hypothesizing variability as one of the major causes of unreliable software application production. We elaborate measurement analysis based approach with engineered design and implemented software application with evaluation using a real time software application (data set) i.e. Intelligent Semantic Oriented Agent based Search I-SOAS (Ahmed, 2009a) (Ahmed, 2009b). The focus of this research is limited to the implementation phase, as we are considering the preprocessed source code of only those projects which are developed using Java Object Oriented Programming language. The remainder of this chapter is organized as follows: section 2 provides introductory details of the field of Software Product Line, section 3 discusses the targeted problems, section 4 presents related research and development work, section 5 describes proposed and implemented solution in the form of a prototype software application and section 6 discusses the results obtained during experimentation using implemented tool by analyzing preprocessed source code of real time product line application i.e. I-SOAS (Ahmed, 2009a).

3 2 Software Product Line Software product line is one of the most recent paradigms initiated in late nineties to meet market demands (cost, time, quality). The idea of software product line was originally initiated by engineering industry for the production of different kinds of hard goods e.g. cars, aeroplanes, heavy machinery etc. The concept was to manufacture high quality goods in shortest possible time, with limited number of resources and budget. The implanted approach was just to assemble already designed and manufactured parts of particular goods (e.g. by some third party manufacturers) to make a new product. This idea of reusability forced software practitioners with a constructive mean to adopt product line approach and produce high quality software products within less time, with limited number of resources and less cost (Ahmed, 2011). In product line approach, software development life cycle splits in to two concurrent phases i.e. Development for Reuse and Development with Reuse. Development for reuse is about to implement such modules which can be integrated with other (compatible) modules to form a complete application as development with reuse. Development for reuse is applied in Domain Engineering where as the development with reuse is applied in Application Engineering (Kolb et al., 2006). Software product line is defined as the family of products designed to take the advantage of their common aspects and predicted variability (DM and CTR, 1999). Commonality and Variability are two key properties of software product line. Commonality represents the common (similar) functionalities in a line of products leading to the concept of reusability and standardization e.g. every database application has to implement a database layer (DBL) to communicate with the relational database management system. If DBL is designed by keeping the concept of reusability in mind then it can be used in every kind of data base application instead of rewriting a new DBL each time from scratch. As a result this will save efforts, time and cost. Variability represents the differences across the line of products. In order to have the better understanding of variability we can take the example of already developed software product line based java application which takes Java preprocessed source code as an input, analyzing it and then visualizing the results. The process of input analysis and visualization of the results is same for every dataset which represents the common behavior whereas the process of analyzing the preprocessed source code is different for each input which represents the variable behavior of the product line application. Variability is identified during the domain engineering and exploited during the application engineering (Pohl et al., 2005). It is resolved by binding from domain engineering to application engineering at binding time (time at which the decisions for a variation point are made) (Chakravarthy and Eide, 2006). Binding can be performed at Compile, Link, Run and Update time. Moreover variability is divided in to external, internal, discrete, continuous and abstract types (Becker et al., 2001) which can be helpful in decreasing the complexity levels and increasing the performance of the project.

4 3 Problem Definitions & Scope Problem 1: Software product line provides a way to develop higher quality products and at the same time it introduces the additional level of complexity that may reduce or eliminate potential productivity gains. In product line engineering multiple sub-products have to be developed and integrated with each other. Managing the process of integration of products is one of the most complex tasks. Software practitioners have little support to cope with this additional level of complexity and gain maximum benefit out of it. Problem 2: In order to quantitatively manage the variability in software product line system, it is mandatory to analyze all the components and the features of the developed system (software application) to identify and trace the variation points and design complexities. Problem 3: One another aspect of preprocessed source code analysis is to apply (some) measures (metrics) for quantitative measurement analysis, which could be helpful in extracting meaningful, design based and statistically helpful information e.g. a complete project structure, line of source code, package and class information etc. Problem 4: One of the main problems regarding project management is the way of result presentation. When the project s preprocessed source code is analyzed, then the output is needed to be presented in well understandable formats. The best way to deliver the results is to represent it graphically. Some researchers have claimed of providing some solutions to these problems but those are still not convincing. We have also tried to address these issues in our research and development. Due to the limited scope of our research, at the moment we have only focused on Java based systems. 4 Related Work / Literature Review The presented literature review in this chapter encompasses only the most relevant approaches i.e. Relation-based Approach (Succi and Liu, 1999), Static Scanning Approach (Viega et al., 2000), Columbus (Ferenc et al., 2004), TUAnalyser & Visualization: (Gschwind et al., 2004), CodeCrawler: (Lanza et al., 2005), Polymorphism Measure (Benlarbi S. and Melo W., 1999), Assessing reusability of C++ Code (Fatma and David, 2002) and Evaluation of Object Oriented Metrics (Denaro et al., 2003). A brief description of each approach is as follows: Relation based Approach; proposed for simplifying the metrics extraction from the object oriented code. In this approach relations are designed like prolog clauses to describe the language entity relationship. Static Scanning; this approach breaks a non-preprocessed code file into a series of lexical tokens and then matches the patterns in that series of tokens. Matching of code is added manually, so that non-regular patterns can be recognized. It does not use the real parsing techniques because of less false negative rate to support interactive programming environments. The resultant series of tokens are then matched with already existing vulnerable database. Static scanning approach is validated with the implementation of ITS4.

5 Columbus; a reverse engineering framework to extract the facts from preprocessed code. It acquires the project information is indispensable way to carry out the extraction process. Gschwind; Pinzger and Gall presented an approach to visualize the extracted information from source code. Compiler first extracts the information from preprocessed source code and stores it into RSF format. This RSF format is then passed as input to Graphviz to produce visual output. CodeCrawler; based on a tool called FAMIX and used to visualize the object oriented source code. This approach visualizes the software metrics and other source code semantics in lightweight 2D & 3D and polymeric views. Polymorphism; a measure method used to identify the software reliability problems in the early stages of software development life cycle. The measurement has been categorized into Static polymorphism and Dynamic polymorphism. Static polymorphism based on the compile time and dynamic is based on the runtime binding decisions. Five metrics are initiated to combine the early identified polymorphism forms with inheritance relationship. Component Reusability; Fatma and David have presented a method for judging the reusability of components and assessing indirect quality attributes from the direct attributes. Method is divided into two phases. First phase is used to identify and analytically validate a set of measurements for assessing direct quality attributes. The second phase identifies and validates a set of measurements for assessing indirect quality attributes. Moreover, a set of relations is also provided which maps directly measurable software quality attributes to another set of indirectly measureable quality attributes. This method is validated in the publication via an empirical study conducted on C++ code components. Giovanni; Mauro and Luigi analyzed the relationships between the object oriented metrics defined by Chidamber and Kemerer (Chidamber and Kemerer, 1994) and fault-proneness across three different versions of this target application. Authors collected the data from three different sources and performed system and integration testing, and then stored the faultiness data in database. Whenever a fault was revealed, references to the version under test and the corresponding faulty code were traced in the database. 5 Approach / Tool Implementation We have tried to analyze the targeted problems, taking advantage of the reviewed literature and using personal research and development experiences, proposing a systematic approach as the solution (Ahmed, 2006). The aim of our solution development is to support software practitioners with a comprehensive approach to cope with additional software complexity introduced by SPL (Ahmed, 2010). Our proposed approach provides a systematic way to analyze, measure and visualize the complex behavior of the system by analyzing preprocessed source code of software application to take advantage in identifying, tracing and resolving the variabilities. As earlier discussed in section 3, in this research our scope is limited as we are focusing only on projects developed using Java to estimate, measure and visualize (Size and Complexity). It could be helpful in predicting the overall behavior of the software product line based ap-

6 plications. This approach consists of three major components as shown in Figure 1 i.e. Analysis, Measurement and Visualization. Figure 1: Three component based approach (Ahmed, 2010). Three components i.e. Analysis, Measurement and Visualization, works in sequential order to analyze preprocessed source code with the application of some useful measures and produces different visual diagrams to help practitioners in developing understanding. Analysis; process to analyze preprocessed source code is initiated in this component. During the analysis part, all the project artifacts and preprocessed source code files are analyzed (tokenized and parsed) to identify the software product line and traditional characteristics, especially those which contribute to increase complex behavior. Measurement; a potential analytical solution to the software project management. Measurement based approaches support project managers in analyzing project performance in a quantitative manner. It provides software practitioners with objective, cyclic way to characterize, control and improve software processes and their outputs. Successful project management is, in turn, the base for meeting aforementioned market demands (CHAOS, 2005). Quantitative project management is actually the way towards the successful project management. It applies measurement analysis to predict the minimum possible cost and time required for software application development. Measurement starts with the definition of quantitative objectives and follows the top-down specification to define respective measures. This phase can be applied to all artifacts of the software development life cycle to measure the performance and improve the quality. It allows characterizing and controlling in a quantitative manner to achieve the organization s business goals by mapping them to software and measurement goals by using such approaches as GQM (Basili et al., 1994). Measurement allows stating quantitative organizational improvement objectives and decomposes them down to measurable software process and product characteristics. This helps project managers to track their improvements and mitigate potential risks. You cannot control what you cannot measure (DeMarco, 1982) Visualization; next component of our approach is the visualization of results obtained during preprocessed source code analysis and quantitative measurement analysis. This approach was required to be implemented in the form of a software tool capable of treating preprocessed (Java based) source code as an input to analyze, measure and visualize the results. It is quite difficult to implement such a comprehensive application because it is not easy to analyze the product line based software applications because of their unpredictable and complex nature (some times). We have implemented a tool to perform targeted operations (Ahmed and Saman, 2010) (Ahmed, 2010). It is divided in to four components i.e., Analyzer, Data Manager, Measurer, and Visualizer; works in a cyclic order as shown in Figure 2 and consisting of five steps:

7 Figure 2: Conceptual Design (Ahmed, Saman, 2010). The conceptual diagram consist of five conceptual (also implemented) steps i.e. Source Code, Analyze, Data Manager, Measurer, and Visualizer, working in a cyclic sequential order to perform preprocessed source code analysis. 1. Input; taking preprocessed source code as input. 2. Analysis; analyzing internal software characteristics e.g. packages, classes, methods, functions, declarations, expressions and conditions. 3. Database; generating results and maintaining them in database. 4. Measurement; calculating preprocessed source code metrics. 5. Visualization; presenting results in different diagrams e.g. graphs, line charts, bar charts and tree maps etc. The implemented application has been developed using freely available tools and technologies i.e. Java (Object oriented software development language), Antlr (a language recognizer which interprets, compiles, and translates grammatical descriptions containing actions in a variety of target languages) (Mark, 2008) (Ashley, 2005), MySQL (a relational database management systems) and Graphviz ( is an open source graph visualization software API used to produce visual representation of structural results in abstract graphs and networks). Designed internal work flow of this application consists of six components.i.e., Source Code Analyzer, Semantic Modeler, Data Manager, Measurer, Visualizer and Editor, as shown in Figure 3. Each of six components altogether works in a sequence to attain the final goal. At first the preprocessed source code of input software application is validated by Source Code Analyzer with the use of a Lexer and Parser (especially designed according to the semantic and syntax of Java programming language using ANTLR). Tokenized preprocessed source code, is then, maintained in designed relational database (using MySQL). Designed Measurer module is applied to the tokenized code to perform quantitative measurement analysis and user requested (selected from graphical user interface) visualization is produced using Graphviz.

8 Figure 3: Internal Work Flow (Ahmed, Saman, 2010). The internal work flow diagram consists of six components Source Code Analyzer, Semantic Modeler, Data Manager, Measurer, Visualizer and Editor. 6 Experimentation Using Implemented Tool To validate the potential and effectiveness of developed prototype application, we have experimented using a real time software application s preprocessed source code. We have used a web application i.e. I- SOAS (Ahmed, 2009a), especially designed for Product Data Management Systems, and developed mainly using Java programming language. I-SOAS is a prototype application proposed to take advantage in implementing an advance Product Data Management System with flexible graphical user interface and intelligent semantic based search. During experimentation, we take the complete project preprocessed source code as input along with all supporting project files. Applied some complexity and size measures to analyze the over all behavior of the application with the estimation of different levels of complexities. Following measures have been applied i.e. File Information Measure (FIM), Number of Artifacts (NOA), Package Complexity Measure (PCM), Package Inheritance Tree (PIT), Number of Children (NOC) and Depth of inheritance (DIT). 1. FIM is to estimate the over all behavior of the project (Figure 4 & 5).

9 2. NOA measures the number of artifacts used by computing direct ancestors (Figure 6). 3. PCM is to measure the level of complexity of each package (Figure 7). 4. PIT estimates the number of ancestors of the package (Figure 8). 5. NOC calculates the number of direct descendent for each class (Figure 9). 6. DIT indicates the rate of fault proneness in application (Figure 10). Figure 4: I-SOAS Multi Colour Tree File Map. The Figure Multi Colour Tree File Map represents different artifacts of project i.e. I-SOAS, analyzed. Blue colour boxes are executable ( exe ) files, yellow colour boxes are Jar Files and green colour boxes are Java Files, pink colour boxes are JPG (image files), brown colour boxes are dll files,.dark blue colour boxes are Java Class files, faint green colour boxes are bitmap files, light gray colour boxes are html files, purple colour boxes are gif files, dark brown colour boxes are database files, light green boxes are SQL script files. As shown in Figure 4, a multicolour file tree map, generated by the developed prototype after project artifact (including source code files) analysis. This map is based on the number of files used in input

10 application (I-SOAS), plotted with respect to the size, format (type) and placement (directory), classified in different colours e.g. files represented in blue boxes are Executable (exe) Files, files drawn with yellow colour boxes are representing Jar Files and files with green colour boxes are representing Java Files, files representing pink colour are JPG (image files) etc. The size of each box is with respect to the size of the file where as the placement of each box is with respect to the placement and association of files with each other and with directory structure. This visual representation can be helpful for the software practitioners in analyzing the over all structure of the project. Preprocessed source code consists of 736 Packages, 876 Classes and total 1619 files, as shown in Figure 5 in the form of a drawn Project overview bar chart. The length of each bar is based on calculated average size of respective files. Figure 5: I-SOAS Project Over View. The Figure project over view consists of three main bars i.e. Packages, Files and Classes, representing three main source code elements. A tree graph is shown in Figure 6, representing the overall inheritance relationships of programmed pre-processed source code based on the number of packages and classes used in the development of I-SOAS e.g. association or inheritance between packages and class hierarchy and relationships. Measure Number of Artifacts (NOA) is used to measure the number of artifacts used by computing direct ancestor(s) for each artifact.

11 Figure 6: I-SOAS Number of Artifact (NOA) Graph. The Figure number of artifact presents a tree graphs consisting of two colored (green and white) interconnected source code elements (artifacts). Green colour represents roots and white colour represents leaves.

12 This kind of visual representation can be helpful for the practitioners in analyzing the overall structure of the packages and classes used in a project. Moreover software practitioners can also take advantage in analyzing the level of complexity of relationships between packages and classes as well. If the number of artifact increases then most probably the number of dependencies between the artifacts will also increase, which ultimately causes the increase in complexity. Higher the number of NOA, higher will be the probability of fault proneness in the product line system. Figure 7 Package Overview presents the bar char drawn representing each package with respect to its size and complexity. Package Complexity Measure (PCM) is applied to measure the level of complexity of each package. This visual representation is helpful for the practitioners to analyze the overall complexity level of used and programmed packages in application. Figure 7: I-SOAS Package Complexity Overview. The Figure I-SOAS package complexity overview is a bar chart representing packages in blue colour and height of each bar represents the level of complexity. Figure 8 Package Structure presents the graph of packages used in I-SOAS, including programmed and used libraries. As shown in the figure, there are 736 packages; default package is the parent namespace. This visual representation is helpful for the practitioners to analyze the overall structure of the packages

13 used in the project; moreover software practitioners can also take advantage in analyzing the complexity in package relationship. Package Inheritance Tree (PIT) measure is used to estimate the number of ancestors of the package. PIT can be very helpful in the indication of fault proneness because package is one of the major components of any product line software application. Every component of project like class, library etc exists inside the package. If the number of package increases, then the number of ancestor will also increase which will raise the complexity. The increase if PIT may possibly increase the number fault proneness in software application. Figure 8: I-SOAS Package Inheritance Tree (PIT). The Figure I-SOAS package inheritance tree is complex tree graph consisting of the relationships between packages (navy blue colour boxes).

14 Figure 9 Number of Children (NOC) provides the visual presentation in the form of a 3D line bar chart, based on the level of complexity of classes in packs depending upon the number of ancestors of each class. Measure NOC is used to estimate the number of direct descendent for each class. NOC helps in the indication of the fault proneness, lower the rate of fault proneness if higher the rate of NOC. Figure 9: I-SOAS Number of Children (NOC). The Figure I-SOAS number of children representing the number of direct descendent for each class in 3D line bar chart. Figure 10 Depth of inheritance (DIT) provides the visual 3D line bar chart of measured ancestors of the each class used in each package. DIT helps in the indication of fault proneness, the larger the DIT, the larger the probability of fault-proneness in the software.

15 Figure 10: I-SOAS Depth of inheritance (DIT). The Figure I-SOAS depth of inheritance provides a 3D line bar chart representing measured ancestors of the each class used in each package. 7 Conclusion The aim of this chapter is to address the importance of preprocessed source code and project artifact measurement for better reliability analysis of software application by visualizing obtained results in different diagrams to take advantage in analyzing over all behavior of software project by predicting the level of complexities at different stages and estimating the rate of fault of proneness as well. To meet aforementioned goals of this research, we have discussed the conceptual architecture of used approach and briefly presented developed prototype, validating its potential strengths and effectiveness with an experiment by analyzing complete project preprocessed source code of a product line application i.e. I- SOAS. During experimentation we have measured preprocessed source code elements, applied size measures (NOC etc.) and inheritance measures (DIT, PIT etc.) along with visual presentations in the form of tree map, graph and chart. Provided visual representation can be helpful for the software practitioners in analyzing the overall structure of the project by examining the composition of packages, classes and their complex relationships to bring out the intensity of fault proneness of any product line software application.

16 Acknowledgment We (authors) are thankful to the University of Wuerzburg Germany for giving us the opportunity to work on this research project. We are thankful to Prof. Dr. Thomas Dandekar for his support during this research. We are also thankful to the blind reviewers and publishers for publishing this manuscript as book chapter. References Ahmed, Z. (2006). Integration of variants handling in M-system NT, Master Thesis, Department of Computer Science, Blekinge Institute of Technology, University of Blekinge Sweden, In Co-operation with Fraunhofer Institute of Experimentells Software Engineering Germany. Ahmed, Z. (2007). Measurement Analysis and Fault Proneness Indication in Product Line Applications (PLA), Chapter 7, Frontiers in Artificial Intelligence and Applications, Volume 161, IOS Int. Publisher, pp , ISBN (print), ISBN (online). Ahmed, Z. (2009a). Proposing Semantic Oriented Agent and Knowledge base Product Data Management, In Emerald: Information Management and Computer Security Journal, Volume: 17, Issue: 5, pp , ISSN: , September. Ahmed, Z. (2009b). Intelligent semantic oriented agent based search (I-SOAS), In Proceedings of the 7th International Conference on Frontiers of Information Technology, Article No. 55. Ahmed, Z. and Majeed, S. (2010). Towards Increase in Quality by Preprocessed Source Code and Measurement Analysis of Software Applications. IST Transactions on Information Technology- Theory and Applications, Vol. 1, No. 1 (2), ISSN , pp Ahmed, Z. (2010a). Towards Performance Measurement and Metrics based Analysis of PLA Applications, International Journal of Software Engineering & Applications, Vol.1, No. 3,pp 66-80, ISSN: (Online), Ahmed, Z. (2011). Integration of variants handling in M-system NT: Empirically evaluated approach towards the identification of correlation between traditional and product line measures, ISBN: , pp. 112, Verlag Dr. Muller (VDM) Publishers. Ashley, J.S. (2005). ANTLR. Basili, V.R., Caldieram, G., Rombach, H.D. (1994). The goal question metric approach. Encyclopedia of Software Engineering, pp , John Wiley & Sons, Inc. Becker, M., Geyer, L., Gilbert, A. and Becker, K. (2001). Comprehensive Variability Modelling to Facilitate Efficient Variability Treatment, Software Product Family Engineering: 4th International Workshop, PFE 2002, Bilbao, Spain, October 3-5. Benlarbi, S. and Melo W. (1999). Polymorphism Measure for Early Risk Prediction, In Proceeding of 21st international conference on software engineering, ICSE 99, Los Angeles USA. Briand, L. and Wüst, J. (2001). The Impact of Design Properties on Development Cost in Object-Oriented System, IEEE Transactions on Software Engineering, vol. 27, no. 11. Chakravarthy, V. and Eide, E. (2005). Binding-time flexibility for managing variability. In Proceedings of the OOPLSA 2005 Workshop on Managing Variabilities Consistently in Design and Code (MVCDC 2), San Diego, CA, October.

17 Chidamber, S.R, Kemerer, C.F. (1994). A metrics suite for object oriented design. IEEE Transactions on Software Engineering, 20(6): Fatma, D. and David, C.R. (2002). A Method for Assessing the Reusability of Object- Oriented Code Using a Validated Set of Automated Measurements, Proceedings of the 2002 ACM symposium on Applied computing, pp , ISBN: Ferenc, R., Beszedes, A. and Gyimothy, T. (2002). Extracting Facts with Columbus from C++ Code. In proceedings of the 6th International Conference on Software. Giancarlo, S. and Liu, E. (1999). A Relations-Based Approach for Simplifying Metrics Extraction. In Department of Electrical and Computer Engineering, University of Calgary University Drive NW, Calgary, AB T2N 1N4. Giovanni, D., Mauro, P. and Luigi, L. (2003). An Empirical Evaluation of Object Oriented Metrics in Industrial Setting, In 5th Caber Net Plenary Workshop. Gschwind, T., Pinzger, M. and Gall, H. (2004). TUAnalyzer Analyzing Templates in C++ Cod, In Proceedings of the 11th Working Conference on Reverse Engineering (WCRE 04) 2004 IEEE. Kolb, R, Muthing, D., Patzke, T. and Yamauchi, K. (2005). Refactoring a legacy component for reuse in a software product line. IEEE International Conference on Software Maintenance (ICSM2005): 18(2), pp , ISSN: X. Lanza, M., Ducasse, S., Gall, H. and Pinzger, M. (2005). CodeCrawler: An Information Visualization Tool for Program Comprehension. In Proceedings of the 27th international conference on Software, ICSE 2005: Pohl, K., Böckle, G. and van der Linden, F. (2005). Software Product Line Engineering Foundation, Principles and Techniques, Upper Saddle River, NJ: Addison-Wesley, pp. 59. Robak, S. and Franczyk, B. (2001). Feature interaction product lines, In Proceedings of Feature Interaction in Composed Systems. von Tom DeMarco. (1982). American Consultant. Volkmann, M. (2008). ANTLR 3, Object Computing, Inc. Viega, J., Bloch, J.T., Kohno, Y. and McGraw, G.. (2000). ITS4: A static vulnerability scanner for C and C++ code, acsac, p. 257, 16th Annual Computer Security Applications Conference (ACSAC'00), December. Weiss, D.M. and Lai, C.T.R. (1999). Software Product-Line Engineering: A Family-based Software Development process. MA: Addison Wesley: Reading MA.