Subrina Anjum Tonu and Ladan Tahvildari

Transcription

1 Investigating Architectural Evolution in Gnumeric Subrina Anjum Tonu and Ladan Tahvildari Department of Electrical and Computer Engineering University of Waterloo Waterloo, ON, Canada, N2L 3G1 Technical Report: # November 23 rd, 2004

2 Investigating Architectural Evolution in Gnumeric Subrina Anjum Tonu and Ladan Tahvildari Department of Electrical and Computer Engineering University of Waterloo Waterloo, ON, Canada, N2L 3G1 {subrina, November 23 rd,

3 Table of Contents 1 Introduction Related Works Gnumeric overview Our Proposed Approach Understanding the Architecture of Gnumeric Conceptual and Concrete architecture MVC architecture of Gnumeric Software Evolution analysis Retrospective Analysis of Core Gnumeric Growing Rate Changing Rate Cohesion Coupling Predictive Analysis Evolution-Sensitive Part Evolution-Critical Part Software Metrics Lines of Code Conclusion and Future Work References List of Figures FIGURE 1: CONCEPTUAL AND CONCRETE ARCHITECTURE OF GNUMERIC... 8 FIGURE 2: MVC STRUCTURE OF GNUMERIC... 9 FIGURE 3: INSIDE VIEW OF MSTYLE.O FILE FIGURE 4: PROPOSED DATA STRUCTURE FOR MSTYLE.O FILE List of Tables TABLE 1: NUMBER OF FUNCTIONS IN EACH RELEASE TABLE 2: NO. OF FUNCTIONS IN EACH OF SUBSYSTEM TABLE 3: NUMBER OF FUNCTION ADDED AND DELETED IN EACH RELEASE TABLE 4: NUMBER OF ADDED AND DELETED FUNCTIONS IN EACH OF SUBSYSTEM TABLE 5: TOTAL NUMBER OF FUNCTION CALLS TABLE 6: NUMBER OF FUNCTION CALLS CHANGED TABLE 7: NUMBER OF FUNCTION CALLS WITHIN EACH SUBSYSTEM IN SEVERAL VERSIONS TABLE 8: NUMBER OF COUPLING OF GUI CONTROLLER WITH OTHER SUBSYSTEM TABLE 9: NUMBER OF COUPLING OF VIEW WITH OTHER SUBSYSTEMS TABLE 10: NUMBER OF COUPLING OF WORKBOOK WITH OTHER SUBSYSTEMS TABLE 11: LINES OF CODES

4 List of Graphs GRAPH 1: GROWING RATE OF CORE GNUMERIC GRAPH 2: GROWING RATE OF DIFFERENT SUBSYSTEMS GRAPH 3: CHANGE RATE OF CORE GNUMERIC GRAPH 4: CHANGING RATE OF SOME MAJOR SUBSYSTEMS GRAPH 5: RATE OF CHANGE IN FUNCTION CALLS GRAPH 6: COHESION IN EACH OF SUBSYSTEM IN SEVERAL RELEASES GRAPH 7: PERCENTAGE OF COUPLING OF GUI CONTROLLER WITH OTHER SUBSYSTEM GRAPH 8: PERCENTAGE OF COUPLING OF VIEW WITH OTHER SUBSYSTEMS GRAPH 9: PERCENTAGE OF COUPLING OF WORKBOOK WITH OTHER SUBSYSTEMS GRAPH 10: LINES OF CODE

5 Abstract An operational software system undergoes a series of changes for many reasons such as the requirements are modified and new features are added to suit changing needs; performance enhancements may be effected to conquer system bottlenecks; and previous errors may need to be corrected. Given that the software systems inevitably evolve over time, we need to understand and track the various changes by extracting and analyzing the architectures of such software systems [2]. Spreadsheets are among the most common type of software in use nowadays [3]. In this project we have examined the structure of several releases of a spreadsheet Gnumeric [4] in particular and tried to determine the evolution of core Gnumeric. We first developed the as-designed (conceptual architecture) architecture, then by using QLDX pipeline we developed the as-built (concrete architecture) architecture of ten releases of Gnumeric, and then we used grok/ql programming language to determine various measures like growing rate, changing rate, cohesion, coupling, resources used etc, in various releases. By these metrics we did some retrospective and predictive analysis on the core architecture of Gnumeric. We conclude that the architecture of Gnumeric is consistent through the releases we analyzed and it has become stable in gunumeric-1.2 series. However, it seems that some part of Gnumeric needs evolution in future releases. 1 Introduction Large software system grows slowly but constantly. Software system must evolve to satisfy various new requirements. If it is not evolved to satisfy the changing needs, the software is of no use. K. Bennet and V. Rajlich even proposed a stage model for the maintenance phase of software life cycle [15].But after many enhancements a critical point is reached where evolution of each release increases complexity. One way to avoid this situation is to identify those modules which need to be evolved. Another way is to identify the critical-component of software which may cause problem due to evolution. The objective of this project is to analyze the evolution of Gnumeric and to do retrospective and some predictive analysis on the evolution of Gnumeric. The analysis involves ten releases of Gnumeric. The releases were triggered by new features added to Gnumeric, by product improvement, by bug fixing, by change in customer demand etc. Our analysis is based on the data extracted from Gnumeric source code by QLDX pipeline (a software extraction tool) and grok/ql script (a relational calculator for doing various queries on a database). We only considered the Core Gnumeric i.e. the files which directly influence the architecture of Gnumeric. So, we can say that we have analyzed the evolution of Core Gnumeric. Henceforth whenever we say Gnumeric we mean Core Gnumeric. We clustered the files of the Core Gnumeric based on the logical dependencies among the modules. We did two types of analysis on Core Gnumeric: Retrospective analysis and predictive analysis. In retrospective analysis we determined the growing rate (based on number of functions) of core Gnumeric, growing rate of each subsystem of Gnumeric, the change rate of the Core and each subsystem (based on added and deleted functions on various releases) of Gnumeric. We also measured the change rate of some syntactic dependencies like cohesion and coupling to determine change of the structural complexity of Core Gnumeric. In predictive analysis we tried to determine the Evolution Critical part i.e. the part of Core Gnumeric that needs to be evolved due to lack of quality and also tried to determine the Evolution Sensitive Part of core Gnumeric i.e. the part which, if 5

6 evolved, may have high impact on other subsystems of core Gnumeric. This may cause problems in the quality of Gnumeric and if all the affected modules are not modified according to the evolution, it may introduce new errors. 2 Related Works We have investigated the architectural evolution of Core Gnumeric. The investigation involves 10 releases of gnumeric. Our goal is to see whether the architecture of Core gnumeric is consistent through the several releases and also to propose some possible improvements in the future releases. There are some other related works. Gall et. al. [5] investigated the structure of several releases of a telecommunication switching system (TSS) based on information stored in a database of product release. They have applied different metrics like number of programs, changing rate, added programs etc. The laws of software evolution have been discussed by Lehman [6]. The organization of the rest of the report is as follows: Section 3 gives a very brief overview of Gnumeric, section 4 describes our approach for doing this project, section 5 describes our conceptual and concrete architecture of Gnumeric and also the MVC architecture of Gnumeric, section 6 describes our retrospective and predictive analysis on the core architecture of Gnumeric and section 7 describes a product metrics (Lines of Code in particular) we have applied on Core gnumeric. In section 8 we have drawn our conclusion. 3 Gnumeric overview Gnumeric is an open source spreadsheet program created and maintained under GNOME [7] project. It s a free software [8] released under GNU GPL [9]. The Gnumeric spreadsheet is developed with the GNU C compiler and the user interface is prototyped and designed using the Glade GUI designer [10].The creator of Gnumeric is Miguel de Icaza and the maintainer is Jody Goldberg. There are other people who are in the development team of Gnumeric. Gnumeric aims for stability, file compatibility, minimal cost transaction, sufficient features set, internationalization, and openness. The latest versions of Gnumeric include numerous improvements over previous versions of Gnumeric. The latest versions of 2.0 series include GTK 2.0, improved functions, file import export, graphing and improved solver. 4 Our Proposed Approach We have done two type of analysis on gnumeric: Retrospective and Predictive. For retrospective analysis we have measured some metrics and these measures worked as a guideline for our predictive analysis. Our work is mainly based on using QLDX pine line and grok/ql programming language. In assignment-1 we developed our conceptual architecture of Gnumeric based on our knowledge about the architecture of spreadsheet and documentation of Gnumeric released by the developers. In assignment-2 we developed the concrete architecture of Gnumeric by using QLDX pipeline and also doing some queries by grok/ql programming language. Our work in this project is the extension of these works. We have parsed ten 6

7 versions of Gnumeric by QLDX pipeline and have done further analysis (both retrospective and predictive) on the core architecture of Gnumeric. We wrote several scripts in grok/ql programming to do various queries like determining the growth rate, changing rate (in terms of function and function calls), cohesion and coupling in subsystem level and even in module level. By ql scripts we extracted data like number of functions added/deleted, number of function calls added/deleted (clinks in Gnumeric.ls.ta Files) etc and we reconfirmed the consistency of these data by lsedit. We have used a shell script also to count the lines of code in several releases of gnumeric. 5 Understanding the Architecture of Gnumeric 5.1 Conceptual and Concrete architecture Conceptual architecture is the high-level model of software which determines how a system is organized and how it operates. It is the as-designed architecture of the software. Actually the conceptual model gives the description of the major components of software or system and the analogies used in design, if any. It describes the concepts which the software exposes to the users including the task-domain data object which users create and manipulate. It also describes the attributes and operations that can be done by the software or the system. Besides, Conceptual architecture also describes the relations among these concepts and the mapping between the task -domain and the concepts [1]. In our conceptual architecture we assumed that Gnumeric is composed of eight major components: Computation engine, File I/O, Plug-in, GUI, Workbook, Utility, Initialization and Bonobo. GUI controller here acts as the controller (MVC architecture) and workbook works as the model and GUI gives output by view.gui takes the user input and based on the action needed it calls the desired modules like Computation Engine or File I/O etc and after the completion of processing view of GUI gives the corresponding output. Figure 1.a shows our conceptual model of Gnumeric. On the other hand, Concrete architecture is the as-built architecture of the software which reflects the source code. So analysis of concrete architecture helps the maintainers in reverse engineering of software to understand the structure of the software. As we built our conceptual architecture based on the documentations of Gnumeric, so it is not strange that the as built architecture also have the same components. Figure 1.b shows our concrete architecture extracted by QLDX pipeline and logically clustering the files of the source code of Gnumeric based on our own intuition and knowledge about spreadsheet architecture and also based on the Gnumeric documentation. 7

8 Plug in Computation Engine Plug in Computation Engine File I/O GUI File I/O GUI Bonobo Workbook Bonobo Workbook Initialization Utility Initialization Utility a) Conceptual Architecture b) Concrete Architecture Figure 1: Conceptual and concrete architecture of Gnumeric From the two architectures i.e. conceptual and concrete architecture, we see that there are some mismatches in the dependencies of the modules. There are some dependencies in the concrete architecture which we did not predict in the conceptual architecture (divergences [12]) and there are also some dependencies which we predicted in the conceptual architecture but we did not find in the concrete architecture (absence [12]). 5.2 MVC architecture of Gnumeric The concrete architecture of Gnumeric was described in details in assignment-2. Now, we will give a very brief description of the MVC (Model View controller a) architecture of Gnumeric. From concrete architecture of Gnumeric we found that the MVC structure exists in Gnumeric. GUI controller module works as the Controller, and View module works as the view of MVC. We have included both these modules into a subsystem named GUI. The data repository of Gnumeric i.e. workbook subsystem works as the Model of MVC. Figure -2 shows the MVC architecture of Gnumeric. 8

9 GUI controller ( Controller ) Sheet Controller Resource management GUI Workbook Controller Print View ( View ) Legend Subsystem Source module Depends on Workbook ( Model ) Figure 2: MVC structure of Gnumeric 6 Software Evolution analysis There are many ways to analysis software evolution and to concentrate on the comparing properties of one release of the software to the next release. This implies that there must be some information kept in each release. By comparing those properties we can check whether the architecture of the software is stable and supported evolution well. We did two type of analysis on the core architecture of Gnumeric [11]: Retrospective Analysis Predictive Analysis Both retrospective and predictive analyses start with the assumption that the goal of the software architecture is software evolution. The retrospective analysis looks through the successive releases of the software to see how smoothly the evolution happened. The analysis is based on various comparing properties of the software through various releases to check if the architecture is consistent through various releases of the software. It checks several releases and determines improvement/degradation of quality through releases. On the other hand predictive analysis provides insight in the software evolution. It can determine the component of software which needs to be evolved due to lack of quality. It can also predict the potential threat due to evolution on one or more architectural aspect like quality, structure etc. By predictive analysis, the future prediction about the resources of the next release of the software can also be determined. Retrospective analysis works as a base for predictive analysis. 9

10 We have written several numbers of grok/ql scripts and ran those scripts on the Gnumeric.ls.ta files which were generated by running QLDX pipeline on the source code of core Gnumeric. The objective of writing these scripts is to determine various kinds of metrics which we will describe in the following section. We have attached all the scripts at the end of the report, and we have numbered those scripts (like script-1, script-2 etc) which we will use as references in the following sections. 6.1 Retrospective Analysis of Core Gnumeric We have done the retrospective analysis on several releases of Gnumeric. We have used some metrics like size of the core Gnumeric and size of each of subsystem in several versions of Gnumeric. These metrics were measured in terms of cfunctions in Gnumeric.ls.ta files. In each graph we put the version number in the x-axis assuming that equal effort was given in each release Growing Rate Growing Rate of the Core Gnumeric By running ql/grok script-1 (CountFunc.ql) we determined the number of functions in each release. Table-1 shows the number of functions in each release and Graph-1 shows the historical development of the size of the core Gnumeric in terms of number of functions. We see that the system had a high growing rate till version Gnumeric But after that it has become stable. If we look at the table-1 we see that only 3 functions are added from release Gnumeric to release Gnumeric We further analyzed these three newly added functions and found that mainly bugs were fixed during these releases (From File news in source code). From table-1 we see that significant number of functions was added in release Gnumeric For determining in which subsystem mainly this growth happened, we determined the number of functions in each of subsystem in each release which is discussed in the following subsection. Version No. of functions Table 1: Number of functions in each release 10

11 Growing Rate No. of functions Versions Graph 1: Growing rate of Core Gnumeric Growing Rate of the each of subsystem of Gnumeric For determining growing rate of each of the subsystem, we extracted data from the Gnumeric.ls.ta files by running script-1 (CountFunc.ql), which is as follows: Subsystem Version Computation Engine File I/O Plug In Workbook GUI Controller(GUI) View (GUI) Bonobo Utility Initialization Table 2: No. of Functions in each of subsystem 11

12 Growing Rate of Subsystems Computation Engine 400 File I/O No. of functions No. of functions Plug In Workbook View (GUI) Bonobo Utility Initialization GUI Controller(GUI) 1950 Version Graph 2: Growing rate of different subsystems From Table-2 we see that subsystems plug in, Workbook, Initialization, and Bonobo are almost stable through the several releases, total 9 functions were added in Utility subsystem from release Gnumeric to Gnumeric and there were some functions which were added or deleted in Computation Engine. But the major change was made in the GUI controller and File I/O subsystem. In Gnumeric GUI Controller contained 1979 functions but in the latest release i.e. Gnumeric-1.2.8, GUI Controller contained 2004 functions which are almost 53% of the total function in that release. Thirteen new functions were also added in File I/O subsystem through the releases. Graph-2 shows the growing rate of each of subsystems and from that graph we see that the subsystems have become stable after release of Gnumeric Changing Rate Changing Rate in terms of Functions in Core Gnumeric By running ql/grok script-2 (Function.ql) we determined the number of functions added and deleted in each release. The total number of function added and deleted gives the changing rate of Core Gnumeric. 12

13 Version # of functions Added #of functions Deleted Total # of change Table 3: Number of Function added and deleted in each release From Table-3 we see that significant number of functions were added and deleted through versions Gnumeric and Gnumeric The major change was done between versions Gnumeric to Gnumeric Total 100 functions were added and 77 functions were deleted between these two versions. From Graph-3 we also see that the major change was done in these two versions and almost 5% change of the total functions was done here. Changing Rate of Core Gnumeric 5 Percentage Added Deleted Total Versions Graph 3: Change rate of Core Gnumeric Changing rate In terms of Functions in each of subsystem of Core Gnumeric Now by running grok/ql script-3 (FunctionSub.ql) we determined how many functions were added and deleted in each of subsystem of core Gnumeric. Table - 4 shows the data extracted by the script-3 where A represents the added function D represents the deleted function and T represents the Total change in functions (added + deleted). 13

14 Version Subsystem A D T A D T A D T A D T A D T A D T A D T A D T A D T Computation Engine File I/O Plug In GUI Controller View (GUI) Workbook Bonobo Utility Initialization Table 4: Number of added and deleted functions in each of subsystem Changing Rate of Subsystems Percentage Computation Engine File I/O Plug In GUI Controller View (GUI) Utility Versions Graph 4: Changing Rate of some major subsystems 14

15 From Table-4 we see that evolution happened only on the subsystem Computation Engine, File I/O, Plug in, GUI Controller (GUI) and View (GUI). There was no function change in Bonobo subsystem, two function changes in workbook and only one function change in Initialization subsystem. Probably these three modules (Bonobo, Initialization and Workbook) have become stable through the releases. From changing rate of each of subsystem (Graph-4) we see that 31% function change was done in Plug In module between version Gnumeric and Gnumeric From Table - 4 we see that between these two versions 38 functions were added and 39 functions were deleted in Plug In subsystem i.e. total 77 functions were changed among the total 243 (from Table-2) functions of plug In. Between Version Gnumeric and Gnumeric Computation Engine was also changed where 13 functions were added and 16 functions were deleted from this subsystem which is almost 6% of the total functions of this subsystem Between version Gnumeric and Gnumeric GUI Controller mainly went under evolution. Between these two versions 70 functions were added and 62 functions were deleted (From Table-4) in GUI Controller. So between these two versions total 132 functions were changed among 1996 functions (Table-2) in GUI controller which is almost 7% of the total functions in this subsystem. Another change was done in subsystem View of GUI between versions Gnumeric and Gnumeric where 12 functions were added and 12 functions were deleted in this subsystem which is almost 7% of the total functions of View Change Rate in Terms of Function Calls By running grok/ql script-4 (clink_f.ql) we determined how many total resources were used i.e. total number of function calls in each version and also the total number of function calls added and deleted between every pair of successive versions we analyzed. Table-5 shows the total number of function calls in each version and Table-6 shows the number of function calls changed between the successive versions. Version No. of function calls Table 5: Total number of function calls Version # Function call Added # Function call Deleted # Function call changed Table 6: Number of Function calls changed Graph-5 shows the rate of change in functions calls. The significant change in function calls was done between versions Gnumeric to Gnumeric which is 13% of the total function calls. We further analyzed these calls and found that the major change was 15

16 done in the GUI controller. The changing rate in function calls (Graph-5) is very similar to the changing rate in functions added and deleted (Graph-4) and it is not surprising that the two rates of change are almost similar. Changing Rate in Function Calls Percentage Added Deleted Total Versions Graph 5: Rate of Change in Function Calls Cohesion Cohesion is a measure of strength of functional relatedness of the elements in a module. One of the objectives in designing good software is to design high cohesive modules. For analysing the cohesion of the subsystems of the Core Gnumeric we ran our grok/ql script- 5 (Cohesion-main.ql) and found the following data: Subsystem Version Computation Engine File I/O Plug In GUI Controller View Workbook Bonobo Utility Initialization Table 7: Number of function calls within each subsystem in several versions 16

17 If we plot the data in graph we get the following graph: Cohesion of Subsystems Percentage Percentage Computation Engine Plug In View Workbook Bonobo Utility Initialization File I/O GUI Controller 0 Version Graph 6: Cohesion in each of subsystem in several releases From Table-7 and Graph-6 we see that GUI Controller is a high cohesive subsystem of Core Gnumeric. Almost 42% function calls are done within GUI Controller (the rightside scale of graph-6). Among other subsystems Computation Engine has 7% function calls within its own module and each of subsystem File I/O, Plug in and View (GUI) have 4% function calls within their own module. Finally, the cohesion of Bonobo is nearly 0.07% because very few function calls are there in this subsystem Coupling Coupling describes the degree to which modules communicate with other modules. By running script-7 (CountCoupling.ql) we determined the number of interactions of each subsystem with other subsystems. Due to page limit of the report we are only showing the coupling with three subsystems: GUI Controller, View and Workbook (the three components of MVC architecture) Coupling with GUI Controller Table-8 and Graph-7 show the coupling of GUI Controller with other subsystem. 17

18 Version Subsystem Computation Engine Plug In Workbook Bonobo View File I/O Utility Initialization Table 8: Number of coupling of GUI Controller with other subsystem Coupling of GUI Controller 100% 90% % 70% Initialization Utility Percentage 60% 50% 40% File I/O View Bonobo Workbook 30% 20% Plug In Computation Engine 10% 0% Version Graph 7: Percentage of coupling of GUI Controller with other subsystem From Graph-7 we see that with subsystem view, GUI Controller has the most coupling. But both these modules are the part of GUI and also the two parts of MVC architecture of Gnumeric. So this coupling is not bad in the sense that the two modules within one subsystem have a higher rate of interaction with each other. GUI controller also has 14% coupling with computation Engine. But it seems logical to us because data processing is done in Computation Engine so there may be lots of interactions with GUI Controller to Computation Engine. GUI Controller also has a high coupling with workbook, but workbook is the data repository so it is logical that GUI needs to access workbook several 18

19 times for data. So it seems to us that the coupling of GUI Controller with other subsystems is quite logical Coupling of View with other subsystem Table-9 and Graph-8 shows the coupling of view with other subsystems. From Graph-8 we see that view has a high rate of coupling with GUI Controller and we described it in the previous section that it is not bad as both the modules are the part of GUI. Subsystem Version Computation Engine Plug In GUI Controller Workbook Bonobo File I/O Utility Initialization Table 9: Number of coupling of View with other subsystems Coupling of View 100% 90% % 70% Initialization Utility Percentage 60% 50% 40% File I/O Bonobo Workbook GUI Controller 30% Plug In 20% 10% 0% Computation Engine Version Graph 8: Percentage of coupling of View with other subsystems 19

20 Coupling of Workbook with other subsystems Table-10 and Graph-9 shows the coupling of workbook with other subsystems. As it is the data repository of Gnumeric so it has a high rate of coupling with other subsystems. Subsystem Version Computation Engine Plug In GUI Controller View File I/O Bonobo Utility Initialization Table 10: Number of coupling of Workbook with other subsystems Coupling of Workbook 100% % Initialization Utility Percentage 60% 40% Bonobo File I/O View GUI Controller Plug In 20% 0% Computation Engine Version Graph 9: Percentage of coupling of Workbook with other subsystems 20

21 6.2 Predictive Analysis For our predictive analysis on the core architecture of Gnumeric we concentrated on two parts: Evolution-Sensitive Part: The part of Gnumeric which has a high estimated impact upon other subsystems and may cause problem due to evolution. Evolution-Critical Part: the part of the Gnumeric which needs to be evolved due to poor quality or bad structure Evolution-Sensitive Part We have written the grok/ql script-6 (ObjFilecoupling.ql) for determining the object files which have provided many resources to its own module and also to the other subsystem. The objective of writing this script is that, if a file provides many resources to other modules then changing the functions in this file will force significant number of changes in the files it is linked with. As such kind of module has a higher number of links with other modules so changing this module may cause problem. This may be a sensitive part of Gnumeric. We found several files which have provided many resources to other modules. But we are not considering all of these files as sensitive parts. Files like sheet.o (provided 361 resources), workbook.o (provided 148 resources) which are part of the repository (model of the MVC architecture), have provided many resources to other subsystems. However, to us this high coupling is logical since subsystem have to access the repository for data processing. And also it is less likely that the repository will evolve significantly. But there are some other files which we may consider as the evolution-sensitive part, which are described in the following section: File Func.o This file is mainly related to handling external function calls which are not built-in and reside in plug in libraries. It is a file in plug in module. Whenever a subsystem needs to call a function which is not a built-in function, they call the function function_call_with_list() (or some variant of it) of this file. This function basically handles the arguments of the function calls to form a standard data type and sends the call to the desired location. Our opinion is that this may be a sensitive part of Gnumeric because if this part is modified in future (for reasons like implementing some new protocol to access library functions), all other subsystems need to be modified File expr.o This is the expression management and evaluation file of Gnumeric and this file is in the Computation Engine subsystem. This file maintains a list of expression in each cell, inserts or deletes expressions and does other works related to expression processing. So, other subsystems call functions in this file when they need to execute any expression. This file has provided 90 resources to other subsystem besides its parent subsystem. So it seems to us that if the developers make any changes in data structure or in expression managing mechanism of this file, the impact in other subsystems will be very high. So this is also an evolution sensitive part of Core Gnumeric. 21

22 6.2.2 Evolution-Critical Part We tried to determine the part of Gnumeric which can be improved in future versions of Gnumeric. As we described in our assignment-2 that Gnumeric does not have any narrow interface, all its functions are totally exposed to each other. So here we are proposing a narrow interface in resource management module in GUI subsystem. The narrow interface in described in the following section File mstyle.o This file mainly deals with the resource management of Gnumeric like setting font style, border style etc. But for each of the particular resources this file has separate functions like individual function for setting boldfaced or underlined font, border size and pattern etc. Investigating the file using lsedit we see a very messy picture (extremely high coupling) (Figure-3). Figure 3: Inside view of mstyle.o file 22

23 Therefore, it seems to us that this file needs evolution in future release. Instead of keeping individual function for each of the particular resource management work, the work can be done by two function i.e. one is get() another is set(). For this an array of resources can be maintained which will have 3 fields: 1) Resource ID, 2) Current Resource value and 3) a link to the possible values of Resources. Link Resource ID Current values Border Font Figure 4: Proposed Data Structure for mstyle.o file Instead of calling each individual function whenever it is needed to set a value of the current resource, the work can be done by calling set() function with parameter resource ID and setting value. On the other hand, to get the value of the current resource by calling get() function with resource ID the current resource value can be extracted. So the whole work can be done using a very narrow interface which we believe will improve the quality of Core Gnumeric architecture. 7 Software Metrics We have applied a product metrics on the Core Gnumeric. Product metrics are measures of the software product at any stage of its development, from requirements to installed system. Product metrics may measure the complexity of the software design, the size of final program (either source or object code), or the number of pages of documentation produced. Among the other product metrics we have applied the most widely used metrics: Size metrics (Lines of code in particular). 7.1 Lines of Code Lines of code are possibly the most widely used metric for program size. It would seem to be easily and precisely definable; however, there are a number of definitions for the number of lines of code [13] in a particular program. These differences involve treatment of blank lines and comment lines, non-executable statements, multiple statements per line and multiple lines per statement, as well as the question of how to count reused lines of code. For determining the lines of code of several releases, we used a shell script which counts lines, not counting comments, blank line and Table-11 shows the lines of code. 23

24 Versions Lines of code Table 11: Lines of Codes lines of code versions Graph 10: Lines of Code 24

25 From Graph-10 we see that in every major release i.e. in releases gnumeric-0, gnumeric- 1.0, gnumeric-1.1 and gnumeric-1.2 there is a significant change in lines of code, but through the minor releases of the major releases, the lines of code is consistent. So it can be predicted that in the future major releases i.e. gnumeric-1.3 there will be also a significant change in lines of code. The 1 st version of gnumeric i.e. gnumeric-0.04 had lines of code where in the latest version i.e. gnumeric it has lines of code. So, almost lines of code have been added through the various releases. 8 Conclusion and Future Work We have tried to do several analyses on the architecture of core Gnumeric. It seems to us that Gnumeric follows the MVC architecture very nicely and by retrospective analysis we found that through the several releases of Gnumeric this architecture is consistent and the architecture has become stable in Gnumeric-1.2 series. But some part of Gnumeric needs evolution. As Gnumeric does not have any narrow interface so some parts can be restructured to follow a narrow interface. We proposed such a narrow interface in the predictive analysis. Due to some technical difficulties we could not parse the very earlier versions of Gnumeric (like Gnumeric-0.99 series). As a future work we can try to parse those versions to get a better insight into the development history of core Gnumeric. Acknowledgements We are grateful to Professor Richard C. Holt for Grok programming language and also to Jingwei Wu for developing QLDX pipeline. 9 References [1] Jeff Johnson, Austin Henderson, Conceptual Models: Begin by Designing What to Design, Interactions, volume 9, issue 1, pp 25 32, [2] David Garlan and Mary Shaw, An Introduction to Software Architecture, Advances in Software Engineering and Knowledge Engineering, Volume I, World Scientific Publishing Company, [3] Vijay B. Krishna et al, Incorporating Incremental Validation and Impact Analysis into Spreadsheet Maintenance: An Empirical Study, Proceedings of the IEEE International Conference on Software Maintenance, pp.72-81, [4] The Gnumeric Spreadsheet available at [5] H. Gall, M. Jazayeri, R. Klösch, and G. Trausmuth, Software Evolution Observations Based on Product Release History, In the Proceedings of International Conference on Software Maintenance (ICSM), pp., [6] M. M. Lehman, Programs, life cycles and laws of software evolution, In Proceedings of the IEEE, pp , [7] [8] 25

26 [9] [10] [11] [12] Murphy, G.C, Notkin, D., and Sullivan, K., Software Reflexion Models: Bridging the Gap between Source and High-Level Models, Proceedings of the Third ACM Symposium on the Foundations of Software Engineering (FSE '95), [13] Everald E. Mills, Seattle University,Software Metrics, SEI Curriculum Module SEI- CM , Dec [14] [15] K. Bennet and V. Rajlich, A staged model for the software lifecycle, IEEE Computer, Vol. 33(7), pp , July

27 Appendix Some Important grok/ql scripts for the analysis of Core Gnumeric are as follows: Some scripts are needed to be run on modified gnumeric.ls.ta files. I have marked those TA files as ModifiedTA files and Kept in a folder in ModifiedTA in my swag account. I have mentioned in each script that which script needs to be run on this ModifiedTA files Script-1: CountFunc.ql //Author: Subrina Anjum Tonu // This script counts the total number of function in a given gnumeric.ls.ta file as well as //total number of functions in each subsystem print "Analyzing " + $1 print " " // open ta file getta($1) // filter functions Functions = $INSTANCE. {"cfunction"} print "Total number of functions : " + # Functions // filter subsystems Subsystems = $INSTANCE. {"csubsystem"} Subsystems = Subsystems - {"gnumeric"} D = contain+ for s in Subsystems { scontains = {s}. D (including non-function) // compute all members contained in s sfunctions = Functions ^ scontains contained in s // filter only functions print s + " contains " + # sfunctions + " functions" } 27

28 Script-2: function.ql //Author: Subrina Anjum Tonu // This script computes total number of functions added or deleted //between two versions of gnumeric. // For running this script successfully the gnumeric.ls.ta files are //needed to be modified little bit. // The path of each cfunction or cobjectfile or data which are in the //form like // /home/subrina/bin-1.2.8/gnumeric-1.2.8/src/stf-parse.o[.text+0x9e0] //needs to be modified like // /src/stf-parse.o[.text+0x9e0] i.e. the version part of the file path //needs to be eliminated. // read first version print "Analyzing " + $1 + " and " + $2 getta($1) // filter cfunctions from INSTANCE Functions = $INSTANCE. {"cfunction"} FuncLabels1 = {} for f in Functions { ffilename = contain. {f} //determine filename containing function f flabel = x = pick(ffilename) y = pick(flabel) // determine label of function f // convert filename to string // convert label to string x = x + "(" + y + ")" FuncLabels1 = FuncLabels1 + {x} } // reinitialize set variables before reading second version $INSTANCE = = eset contain = eset getta($2) // filter cfunctions from INSTANCE Functions = $INSTANCE. {"cfunction"} FuncLabels2 = {} 28

29 for f in Functions { ffilename = contain. {f}//determine filename containing function f flabel = x = pick(ffilename) y = pick(flabel) // determine label of function f // convert filename to string // convert label to string x = x + "(" + y + ")" FuncLabels2 = FuncLabels2 + {x} } T1 = FuncLabels1 - FuncLabels2 T2 = FuncLabels2 - FuncLabels1 T3 = T1 + T2 print "Number of deleted functions " + # T1 print "Number of added functions " + # T2 print "Number of functions changed " + # T3 29

30 Script-3: functionsub.ql //Author: Subrina Anjum Tonu // Computes Number of Functions added or deleted between two versions // of gnumeric at the subsystem level. // For running this script successfully the gnumeric.ls.ta files are // // needed to be modified little bit. // The path of each cfunction or cobjectfile or data which are in the // form like // /home/subrina/bin-1.2.8/gnumeric-1.2.8/src/stf-parse.o[.text+0x9e0] // needs to be modified like // /src/stf-parse.o[.text+0x9e0] i.e. the version part of the file path // needs to be eliminated. // read first version print "Analyzing " + $1 + " and " + $2 getta($1) // filter csubsystems SubSystems = $INSTANCE. {"csubsystem"} SubSystems = SubSystems - {"gnumeric"} // filter cfunctions from INSTANCE Functions1 = $INSTANCE. {"cfunction"} Contain1 = contain AllContain1 = contain+ Name1 // reinitialize set variables before reading second version $INSTANCE = = eset contain = eset // read second version getta($2) // filter cfunctions from INSTANCE Functions2 = $INSTANCE. {"cfunction"} Contain2 = contain AllContain2 = contain+ Name2 for s in SubSystems { // for each subsystem // for first version scontains1 = {s}. AllContain1 // compute set of objects // contained by s (including // nonfunctions) sfunctions1 = scontains1 ^ Functions1 // filter functions contained by // s 30

31 // convert function names to labels FuncLabels1 = {} for f in sfunctions1 { by s in first version // for each function contained ffilename = Contain1. {f} // determine filename // containing function f flabel = {f}. Name1 x = pick(ffilename) y = pick(flabel) // determine label of function f // convert filename to string // convert label to string x = x + "(" + y + ")" FuncLabels1 = FuncLabels1 + {x} } // for second version scontains2 = {s}. AllContain2 // compute set of objects // contained by s (including nonfunctions) sfunctions2 = scontains2 ^ Functions2 // filter functions contained // by s // convert function names to labels FuncLabels2 = {} for f in sfunctions2 { // for each function contained // by s in second version ffilename = Contain2. {f} flabel = {f}. Name2 x = pick(ffilename) y = pick(flabel) // determine filename // containing function f // determine label of function f // convert filename to string // convert label to string x = x + "(" + y + ")" FuncLabels2 = FuncLabels2 + {x} } } print "Change in " + s print " " T1 = FuncLabels1 - FuncLabels2 T2 = FuncLabels2 - FuncLabels1 T3 = T1 + T2 print "Number of deleted functions " + # T1 print "Number of added functions " + # T2 print "Number of functions changed " + # T3 print " " 31

32 Script-4: clink_f.ql //Author: Subrina Anjum Tonu // Computes the difference between the number of function calls between // two versions of gnumeric // For running this script successfully the gnumeric.ls.ta files are // // needed to be modified little bit. // The path of each cfunction or cobjectfile or data which are in the // form like // /home/subrina/bin-1.2.8/gnumeric-1.2.8/src/stf-parse.o[.text+0x9e0] // needs to be modified like // /src/stf-parse.o[.text+0x9e0] i.e. the version part of the file path // needs to be eliminated. // read first version print "Analyzing " + $1 + " and " + $2 print " " getta($1) //print "Total # of entries in clinks : " + # clinks // filter cfunctions from INSTANCE Functions = $INSTANCE. {"cfunction"} // replace function names with Objectfilename(functionname) FuncLabels1 = eset for f in Functions { ffilename = contain. {f} // determine filename containing function f flabel = x = pick(ffilename) y = pick(flabel) x = x + "(" + y + ")" // determine label of function f // convert filename to string // convert label to string // x = filename(function name) T = {f} X {x} FuncLabels1 = FuncLabels1 + T } // filter function <-> function relations from clinks clinks = id (Functions) o clinks o id (Functions) //print "Total number of function calls " + # clinks // for each (x,y) in clinks replace y with its label 32

33 clinks = clinks o FuncLabels1 // reverse FuncLabels1 relation: replace (x,y) with (y,x) revname = inv FuncLabels1 // for each (x,y) in clinks replace x with its label clinks = revname o clinks clinks1 = clinks print "Total # of Function calls in " + $1 + " " + # clinks1 name1 = FuncLabels1 revname1 = revname // clear previous data clinks = eset Functions = = eset revname = eset $INSTANCE = eset // read second version getta($2) //print "Total # of entries in clinks : " + # clinks // filter cfunctions from INSTANCE Functions = $INSTANCE. {"cfunction"} // replace function names with Objectfilename(functionname) FuncLabels2 = eset for f in Functions { ffilename = contain. {f} // determine filename containing function f flabel = x = pick(ffilename) y = pick(flabel) x = x + "(" + y + ")" // determine label of function f // convert filename to string // convert label to string // x = filename(function name) T = {f} X {x} FuncLabels2 = FuncLabels2 + T } // filter function <-> function relations from clinks clinks = id (Functions) o clinks o id (Functions) 33

34 //print "Total number of function calls " + # clinks // for each (x,y) in clinks replace y with its label clinks = clinks o FuncLabels2 // reverse FuncLabels1 relation: replace (x,y) with (y,x) revname = inv FuncLabels2 // for each (x,y) in clinks replace x with its label clinks = revname o clinks clinks2 = clinks print "Total # of Function calls in " + $2 + " " + # clinks2 temp1 = clinks1 - clinks2 print "function calls deleted " + # temp1 temp2 = clinks2 - clinks1 print "function calls added " + # temp2 temp3 = temp1 + temp2 print "function calls changed " + # temp3 34