Software Visualization Revolution Based on Complexity Science - An Introduction to NSE Software Visualization Paradigm

Transcription

1 Software Visualization Revolution Based on Complexity Science - An Introduction to NSE Software Visualization Paradigm Po-Kang Chen 1, Jay Xiong 2 1 Y&D Information system, Inc. USA 2 NSEsoftware, LLC., USA Abstract This article presents a component of the Nonlinear Software Engineering paradigm (NSE) the NSE software visualization paradigm, with which the automatically generated charts and diagrams are colorful, interactive, holistic, virtual, dynamic, and traceable. It is innovated for making the entire software development life-cycle and the obtained work products visible. "One picture is worth ten thousand words." (Chinese idioms) a holistic, interactive, colorful, visual, dynamic, and traceable chart/diagram will be more useful in the description of a complex software product. NSE software visualization paradigm makes a software product much easier to develop, understand, test, and maintain. Keywords: Software Visualization, Software Diagramming, Call Graph, Logic Diagram, Control Flow, Tool, NSE 1. introduction - the old-established software engineering visualization paradigm is outdated The old-established software engineering visualization paradigm is outdated because it is: a. based on reductionism, and superposition principle that the whole of a system is the sum of its parts - so that almost all diagramming tasks and activities are performed locally and partially. b. not Holistic often the application results obtained consist of many small pieces without a complete chart/diagram to show an entire complex software product. c. not automated in most cases - most charts/diagrams are created using graphic editors, not automatically generated. d. not interactive - most charts/diagrams generated are not interactive, hard to manipulate. e. not traceable - even if a complete chart/diagram for an entire software product can be obtained using a few diagramming tools, it is still useless because that without traceability and the capability to highlight an element with all of the related elements, there are too many connection lines to make the chart/diagram hard to view and hard to understand. f. not accurate - often when the source code is modified, the generated charts and diagrams can not be automatically updated to keep consistency with the source code. g. not precise - for instance, when a logic diagram is used to show the result of program test coverage measurement, it can not show whether an invisible else part (a if statement without an explicit else part) is tested or not. Almost all existing visualization tools can not graphically show whether a condition in a decision statement is tested or not when applied to show the result of MC/DC (Modified Condition/Decision Coverage) test coverage measurement results. h. often not consistent with the source code - the charts/diagrams obtained are often not consistent with the source code after software modification. i. not consistent among all related charts and diagrams - often they are created/generated with different formats using different information, hard to keep consistency among them. j. not virtual - the charts and diagrams obtained are stored in hard copies or XML or Postscript format in the memory and/or hard disk, requiring much more spaces to store and long loading time to display. k. not complete -the traditional software engineering visualization techniques and tools do not integrated together to efficiently support the following visualizations: visualization of the entire software engineering lifecycle visualization for software inspection visualization for software testing visualization for software maintenance visualization for the source code of an entire software product visualization of dynamic program behavior visualization for software debugging 2. The Revolutionary Solution Offered by NSE Visualization Paradigm The revolutionary solution offered by NSE[1] for software visualization will be described in details in this paper late. Here is the outline of the solution: a. Based on nonlinear thinking and complexity science b. Holistic c. Automatic

2 d. Interactive e. Traceable f. Accurate g. Precise h. Consistent among all related charts and diagrams display incremental unit test order or the related test coverage and quality data using bar graphics overlaid on each object-box (module-box) to help users view the overall results of testing and quality measurement. J-Chart is useful in system design, understanding, inspection, test planning, test result display, and reengineering. i. The J-Chart notations are shown in Fig. 1. Linkable automatically between different charts and diagrams j. Virtual k. Complete in software engineering visualization, including A comparison between J-Chart and the most traditional call graphs visualization of the entire software engineering lifecycle J-Chart Traditional visualization for requirements engineering Call Graph visualization for design engineering Is it holistic for directly showing a very visualization for coding engineering complex software product? Yes No visualization for software inspection visualization for software testing visualization for software maintenance Is it interactive for highlighting a path or getting related information? Yes No visualization for software Is it traceable to highlight a module with the verification/validation all related modules? Yes No *1 visualization for software architectures Is it supported to use a module as the root to visualization for the source code of an entire software product generate a sub-chart? Yes No visualization for reverse engineering visualization of dynamic program behavior visualization for software debugging Can a bar-chart be added to a module-box to show related information? Yes No 3. The Foundation for Establishing NSE Visualization Paradigm Can the control flow diagram be linked from NSE software visualization paradigm is established through FDS (the Five-Dimensional Structure Synthesis method - a a module-box? Yes No paradigm-shift framework innovated by me) by complying with the Can a bottom-up coding orders be assigned essential principles of complexity science, particularly the to the modules? Yes No Nonlinear principle and the Holism principle with NSE software When used for software version comparison, can visualization paradigm, almost all diagramming tasks/activities are performed holistically and globally to make the entire software different colors be used to show un-changed product and the entire software development process visible. modules, changed modules, deleted modules, 4. 3J graphics (J-Chart, J-Diagram, and J-Flow) The 3J graphics (J-Chart a new type call graph, J- Diagram a new type logic diagram, and J-Flow a new type control flow diagram) are innovated by me and implemented by me and my colleagues. J-Chart/J-Diagram/J-Flow is a trinity: an Object-Oriented and structured chart/logic diagram/control flow diagram, the chart/diagram generator which is always running when the chart/diagram is shown, and the interface (using the chart/diagram itself) between the generator and the user for controlling the chart/diagram dynamically. J-Chart J-Chart not only can be used to represent the class inheritance relationship, the function call graph, and the classfunction coupling structure graphically, but can also be used to Can the source code be directly edited from a module-box? Yes No Can the logic diagram be linked from a module-box? Yes No and added new modules separately? Yes No *1: Some tools claim that they can provide dynamic function call graph, but I have not seen their application examples provided. J-Diagram J-Diagram not only can be automatically generated from source code in all levels including the class hierarchy tree, class structure diagram, and the class member function logic diagram with un-executed class/function/segments/conditions highlighted, but also can be automatically linked together for an entire software product to make the diagrammed source code traceable in all levels. J-Diagram can be automatically converted into J-Flow diagram. J-Diagram is particularly useful in Object-Oriented software understanding, inspections, walkthroughs, testing, and maintenance. J-Diagram notations are shown in Fig. 2. Interactive and

3 traceable J-Diagram not only makes a software product much easier to read, understand, test, and maintain, but also makes the code inspection and walk through much easier to perform in a semi-automated way (see Fig. 5 B1). The major differences between J-Diagram and most Flow Charts J-Diagram Flow Charts Is it structured? Yes No Can it show an entire software product very complex? Yes No Is it uniqueness? Yes No Is the location of the program logic indicated? Yes No Can it show the result of test coverage measurement? Yes No Can it show the branch execution frequency? Yes No Does it offer traceability between related elements? Yes No Can it be converted to a control-flow diagram? Yes No Does it exist virtually without huge space to store? Yes No Interactive and traceable J-Diagram not only makes a software product much easier to read, understand, test, and maintain, but also makes the code inspection and walk through much easier to perform in a semi-automated way. J-Flow Most traditional control flow diagrams are un-structured. They often use the same notation to represent different program logic, and cannot display the logic conditions and the source code locations. J-Flow diagram, on the other hand, is Object-Oriented and structured, uses different notations to represent different logics with capability to show logic execution conditions and the corresponding source code locations. J-Flow is particularly useful in logic debugging, path analysis, test case and code correspondence analysis, and class/function level test coverage result display with unexecuted elements (path, segments, and unexecuted condition outcomes) highlighted. The notations of J-Flow diagram are shown in Fig. 3. Interactive and traceable are the important features of J-Flow diagram, particularly useful for software testing. The major differences between J-Flow and traditional control flow diagram: J-Flow Is it structured? Yes No Can it show an entire software product very complex? Yes No Traditional Control Flow Is it uniqueness? Yes No (arbitrary) Is the source code locations of the control flow indicated? Yes No Can it show the result of test coverage measurement? Yes No Can it show the branch execution frequency? Yes No Can it be automatically converted to a logic diagram? Yes No Can it highlight a path with most untested elements? Yes No Does it exist virtually without huge space to store? Yes No Interactive and traceable are the important features of J-Flow diagram, particularly useful for software testing. 5. Applications NSE Software Visualization Paradigm has been successfully applied in the entire software development process and the maintenance process for a software product development. Figure 4 shows some application examples of J-Chart, J- Diagram, and J-flow separately. Figure 5 shows some application examples combining J-Chart and J-Diagram together, J-Chart and J-Flow diagram together, etc. 6. Conclusion NSE software visualization paradigm is based on complexity science, complying with the Nonlinearity principle and the Holism principle, so that with NSE almost all visualization tasks/activities are performed holistically and globally to automatically generate virtual, interactive, colorful, and traceable 3J graphics (J-Chart, J-Diagram, and J-Flow) innovated to make the entire software development process and the obtained work products visible. NSE software visualization paradigm makes a software product much easier to design, understand, test, and maintain. References [1] Jay Xiong, Jonathan Xiong, A Complete Revolution in Software Engineering Based on Complexity Science, WORLDCOMP'09 SERP (Software Engineering Research and Practice 2009), [2] Brooks, Frederick P. Jr., The Mythical Man-Month, Addison Wesley, 1995, P249.

4 Non-member function Press the right mouse button to pop up a function menu. Member function Press the right mouse button to pop up a member function menu. Macro function Press the right mouse button to pop up a function menu. Overloading non-member function Press the right mouse button to pop up an overloading menu. Overloading member function and virtual function Press the right mouse button to pop up a function menu. Overloading member function Press the right mouse button to pop up a function menu Virtual function Press the right mouse button to pop up a function menu Class Press the right mouse button to pop up a class menu. Template Class Press the right mouse button to pop up a class menu. Fig. 1 J-Chart notations

5 Fig. 2 J-Diagram notations

6 Fig. 3 J-Flow notations

7 (A1) (B2) A2 (C1) (Bi) (C2 ) Fig. 4 Application examples of 3J graphics - A1: a call graph shown in J-Chart notations with test coverage analysis result (a small bar chart on the bottom of each module-box presents the percentage of the source code tested) ; A2: A call graph shown with Cyclomatic complexity (the number of decision statements) measurement result, and the traceability tracing a module with the all related modules calling and called by it; B1: A J-Diagram shows a program logic and the related information as well as the traceability facility; B2: A J-Diagram shows that the logic diagram is independent from the writing styles of source code; C1: A J-flow diagram used for semiautomated test case design by automatically choosing a path with most untested elements and the test conditions extracted; C2: A J- Flow diagram used for automated debugging (through an EXIT word automatically added at the runtime error location).

8 (A1) (B2) (A2) (C1) (B1) C2 Fig.5 Combination applications of the 3J graphics A1: An overview of the test coverage measurement results of an entire software product shown holistically in J-Chart with the untested branches and untested conditions of a module being highlighted in J-Diagram using small black boxes; A2: An overview of the performance measurement result of an entire software product shown holistically in J-Chart with the branch execution frequency of a module shown in J-Flow diagram for locating the performance bottleneck easier; B1: A J-Chart showing the version comparison result of an entire software product (where a unchanged module is shown in blue, changed in red, deleted in brown, and added in green) with the detailed differences of the source code of a changed module shown in different colors in two separated Windows; B2: AN example of converting J-Diagram to J-Flow diagram automatically; C1: Tracing a test case (automatically shown in blue) to the source code with the tested segments highlighted in red color in J-Flow diagram; C2: Tracing a source code segment shown in J-Flow (automatically shown in blue) to find the corresponding test cases (in red) and the related documents open.