Application Overview

Panorama C/C++ is a multi-user software engineering environment that can help software developers throughout software life cycle to increasing software productivity, improve software quality, and reduce cost in almost all processes of software engineering as show below.

New system development support

Daily software programming, testing, and quality assurance support for a new or existing system

Re-engineering support

Other applications

New system development support

Maintainable new system design

With any software system, a good design is the basic foundation. Since today's software systems are much more complex, without a clear, detailed design, the system simply cannot be built. Panorama is designed to solve many problems with the current physical design methods for developing a new software system.

Problems

  1. System design is often inefficient: too much time is spent on drawing design diagrams manually or using semi-automatic graphic editors.
  2. Different kinds of design diagrams such as class inheritance charts, function call graphs, and program decomposition trees have to be drawn separately, even using different graphic editors.
  3. Different design diagrams for parts of the same system are often inconsistent because they are often drawn using different graphic editors or by different designers.
  4. Keeping track of multiple static design diagrams is difficult; locating the required static design diagrams can also be time consuming.
  5. It is hard to decompose or to get a complete overview of a large system because the size of a diagram drawn by hand using a graphic editor is limited by the screen size of the monitor. In reality, both small group diagrams and a complete dynamic overview diagram of the entire system are needed. Using the graphic editors, however, the user has only the small group diagrams, which makes it difficult to see the detailed connection between modules in different groups.
  6. The systems designed are hard to modify. When the designer changes something in the design of a new system, he/she must redraw all related design diagrams.
  7. The systems designed are hard to maintain because the design diagrams and other documents are often out of date, and do not correspond to the final code.

Panorama's solution

  1. Allows the user to directly use the C/C++ programming language in system physical design for describing the high-level system decomposition. The high-level system description file in C/C++ contains only a skeleton structure of the program.
  2. Offers full automation of design diagramming: generates all kinds of design diagrams directly from the same high-level description files to give a complete overview of a large and complex system.
  3. Ensures consistency among the design diagrams and charts because they all come from the same description files.
  4. Saves space in storing diagrams and time in searching for the diagrams, because those design diagrams are generated quickly and dynamically though the internal repository.
  5. Provides a complete overview of a large and complex system. User can view any part of the diagram/chart dynamically.
  6. Enables users to directly modify the design from the chart thorough the description files; automatically updates the design diagrams.
  7. Makes the system designed easy to maintain. In the coding phase, if the programmer discover that the system structure needs to be changed, he can change it accordingly in the code. Now that the code is different from the original design, he/she can run Panorama C/C++. It will regenerate all the related design diagrams using the real source code (modified from the design description files) to ensure consistency between the design and the coding.
  8. The key to making the designed system maintainable and ensuring consistency between design and coding is generating both the design diagrams and the executable program from the same source code.

Less-bug and less-risk coding

Coding today's large, complex system is difficult. The pressure of coding schedules often cause software engineers to hurry development at the cost of inadvertently making expensive mistakes. Panorama C/C++ can solve many of the problems with current software coding methods.

Problems

  1. It is easy to inadvertently create bugs because the system is often coded in an unsystematic order.

    For example, when a programmer writes a call to a module that has not been coded, he/she cannot view the detailed code of the called module to check its type, the number of arguments, or the order of arguments. Often the programmer may think he/she knows the information already, but can still easily make mistakes in the module call statements, such as missing arguments or wrong argument order.

  2. Not coding and testing critical modules and related modules first can be wasteful.

    In a new system, if the system requirements cannot be satisfied by certain critical modules and related modules, the system can not built or must use different approach. If other un-critical modules have been coded first, the user will have wasted his coding effort.

  3. Coding and design have become two separate processes, so ensure consistency between the two is difficult.

    The programmers may find that the high-level system decomposition is not detail enough to guide coding. Furthermore, they may also find that parts of the design will not work or can be improved. Because design modification is too time-consuming, changes are often implemented without upgrading the design, especially when a deadline is approaching.

Panorama's solution

  1. Assigns a bottom-up coding order in the generated class hierarchy charts and function call graphs; allows coding directly from the generated class hierarchy chart or function call graph.

    User can directly code using the design description files (see the section "Maintainable new system design"). Following the coding order assigned, when the user codes a module, all modules called by it must have been coded already. The user can click on a called module box to view the detailed code when writing a module call statement to reduce module Fan-in/Fan-out bugs.

  2. Assigns higher coding priority to the critical modules and the related modules, so the user can code and test those critical modules and the related modules first, before coding any other modules.

    If system requirements can not be satisfied by certain critical modules so the system can not be build or must change the methodology, the user saves both time and money because other un-critical modules have not yet been uncoded.

  3. Makes design pre-coding and coding further design.

    Coding consists of modifying the design description files into the final source code. When programmers needs to change the system design, they can use Panorama to re-generate the related design diagrams directly from the updated new description files, which are also the source files for the system. This way, the two processes are always consistent.

Diagram-based logic debugging

Most software engineers will agree that debugging is a big headache: much of it has to be done manually. In addition, the more complex a program is, the harder debugging, particularly logic debugging, becomes. Panorama C/C++ can help the engineers deal with the problems in current logic debugging methods.

Problems

  1. Find logic errors can be very difficult because a program with logic bugs (such as a decision statement with a loop written outside instead of within the decision statement) may seem to execute normally, but generate the wrong result. Debuggers are often not helpful. So manual logic debugging techniques such as code reading and logic analysis are used in logic debugging. But performing logic debugging using a list of the source code is time-consuming: code written in textual format is hard to read and understand.
  2. Control flow diagrams that eliminates coding details and clearly shows the logic elements of a program can be used for quick logic debugging, particularly by programmers who are familiar with the algorithm implemented by the code. However, the control flow diagrams generated by most tools are unstructured, and hard to read themselves. Moreover, they use the same notations to represent different program logic and cannot show the conditions of a decision and its source code location.
  3. Using traditional procedural logic diagrams such as flow charts for detailed logic debugging is inefficient, because those diagrams are often unstructured as well. Some diagramming tools can generated structured Action Diagram directly from source code. However, Action Diagram is a line-based diagrams, not a block-based diagram; it cannot separate the condition part and execution part of a decision. So Action Diagram is not an ideal tool for logic debugging.
  4. The control flow and logic diagrams generated by most tools cannot display code segment execution frequency and test coverage data, which can be very useful in finding logic problems.

Panorama's solution

  1. Makes source code much easy to read and understand by diagramming it to help software engineers perform logic debugging much easy

  2. Provides software engineers with a quick overview of their program logic by generating J-Flow diagrams directly from the source code.

    J-Flow diagram is structured, uses different notations to represent different logic, and can show the conditions and the source code locations of decision statements to help engineers find logic problems quickly.

  3. Exposes the detailed procedural logic of a program further using J-Diagram.

    J-Diagram is also structured, uses different notations to represent different logic with its execution conditions and source code locations and program execution levels (the first level begins from the entry point of a program module, and the next level begins when the condition of a decision statement is satisfied). J-Diagram is particularly useful for the logic debugging of a complex program module.

  4. Helps engineers perform logic debugging more efficiently by adding the data of procedure/segment execution frequency and test coverage on the J-Flow and J-Diagram generated with unexecuted elements highlighted.

    Those data are very useful in finding logic debugging. For instance, the user can look into whether a condition and its execution part should be executed equal number of times, or whether a segment executed but not a related segment? Besides those, Panorama also pinpoints the unused classes, modules, and labels to help engineers find potential logic problems: why they are written in the system but never used.

Source-level program termination and run-time error locating

When a program terminates unexpectedly or normally but with the wrong result, a programmer may need to locate the termination point for debugging or program analysis. This can be difficult without using an automatic tool like Panorama C/C++.

Problems

  1. Program termination analysis is one of the major software testing tasks. However, locating where a program terminated normally can be difficult, because there may be many different termination points in a program. This makes it hard to match the analysis of the test cases to the corresponding program termination point.
  2. Locating where a program instrumented for test coverage analysis terminates unexpectedly is difficult. Identifying why the program terminates unexpectedly is even more difficult. Since most test coverage analysis tools do not include a debugger, the user can do either test coverage analysis or debugging, but not both at the same time.
  3. When a program being tested goes into an infinite loop, the programmer can terminate the execution of the program (by pressing CTRL-C or other commands). Informing the programmer of the location of the infinite loop will be very helpful for debugging. Most existing testing tools, however, do not provide the capability.
  4. Although some software development tools may tell the user where a program terminated unexpectedly, the locations are shown in binary code, which is hard to read and understand. Even the few tools that may tell the user where a program terminated unexpectedly in source level, the reports are shown in hard-to-read textual format.
  5. Most test tools cannot show the test frequencies with the code. Not knowing the execution process and the exact execution control flow makes it difficult for the programmer to locate quickly the bugs.

Panorama's solution

  1. Pinpoints the termination location automatically for a program terminated normally to help you perform easily program termination analysis with your test cases.
  2. Also locates where an program that has been instrumented for test coverage data terminates unexpectedly and identifies most causes for the termination automatically to help you remove the bugs quickly. Those causes include
    bus error,
    segmentation violation,
    arithmetic exception,
    illegal instruction,
    bad argument to system call,
    cpu time limit exceeded,
    stop signal generated from keyboard,
    abort,
    quit, and
    interrupt
  3. Also identifies infinite loops after user has manually terminated the program.
  4. Shows the termination location in source segment level on J-Flow diagrams with the corresponding source code.
  5. Marks the J-Flow with code execution frequencies and test coverage results to help users find easily the related problems. When the user clicks on the segment in the J-Flow where the program terminates, Panorama C/C++ highlights automatically one or more paths passing through the segment.
    In many cases, a program terminates because of the problems that exist elsewhere. For instance, a program may terminate when division by a variable with zero value occurs, but the real problems is why and when a zero is assigned to the variable.

Daily software programming, testing, and quality assurance support for a new or existing system

Efficient module-level source editing and safe code modification

rogramming a large system is a complex and time-consuming task that requires a lot of hard work. Panorama C/C++ can help make the coding and modification task easier for the software engineers.

Problems

  1. Editing code using existing file-based method is inefficient. When there is a module needs to be changed, a programmer must remember which file contains that module, then open that file and search for the module. Since today's complex systems may contain thousands of modules, this method clearly is insufficient.
  2. Remembering which directory contains a source file can be difficult, particularly when a source file is shared by multiple projects in a network environment.
  3. Code modification can be risky. If a programmer changes a module, he or she must check the effect on other modules: even a small change in a module can introduces inconsistencies in other modules of the system. Identifying which modules may be affected when a module is changed can be difficult without a module cross reference tool. It is also difficult to locate all the derived classes when a base class is changed, without a class hierarchy analysis tool. This makes it easy to overlook inconsistencies created by changes in the code
  4. When a module is changed, finding all the detailed source location of module call statements to the module can be a messy job.
  5. Precisely locating all the function calls to an overloading function is even more difficult, because there may be other function calls to different functions with the same name.
  6. When the programmer changes how a global or static variable is used, he/she needs to know which code statements may be affected by the change. Without a data analysis tool, however, it is very difficult to locate where a global/static variable is defined, changed, and used.

Panorama's solution

  1. Enables software engineers to edit the definition of a function or class directly from the J-Charts generated. They can simply click on a module-box in the system call graph or class hierarchy chart to open the corresponding definition in a source file or a high-level design description file for editing.
  2. Frees the engineers from memorizing which source file contains the definition of a module or class and which directory in the network contains that source file, also saves them from having to search for the source file, open it, and locate the definition of the module or class being modified, and allows the engineers the flexibility to select the editor of their choice.
  3. Highlights on the function call graph all the functions calling or called by the function being modified to help the engineers identify what modules may also need to be modified. Panorama C/C++ can also highlight on the class hierarchy chart all derived classes of a base class being modified to help you avoid the change effect.
  4. Lists automatically all the detailed source locations of module calls to a module being modified to save time and effort.
  5. Also identifies clearly all the corresponding function calls to an overloaded function being modified.
  6. Reports automatically all the information about a global/static variable, including where it is defined, used, and changed, to help the engineers safely make a change.

Assisted code understanding, inspection, and walk-through

Code inspection has always been the most effective way to find bugs. With today's software systems, however, the source code can be very complex. Reading through it line by line to understand it and locate bug is a difficult task. Panorama C/C++ provides an easier and more efficient alternative.

Problems

  1. Understanding today's software systems is difficult because they have become larger and more complex, and often the system documents cannot be found or do not correspond to the actual code.
  2. Code written in many files in textual format is hard to read. To thoroughly understand a software system, the software engineers need quick access to both the high-level system overview chart and the detailed procedural logic diagram of each module. But most software engineering tools can only provide either program hierarchy tree or the detailed procedural logic diagram of a module. Even the few tools that provide both do not automatically link them. A lot of time and effort is wasted in going back and forth between the two.
  3. Code inspection and walk-through is the best human testing technique: it can be used to find about 50% of bugs. However, code inspection and walk-through is very difficult to perform because when the users read a function call statement calling another function, the users may want to check whether the parameters sent from the caller to the called function are correct or not, so they need to read the detailed code of the called function immediately, but where the called function is? it may not be written in the same file and stored in the same directory. Also when the users read a global variable, they may want to know there is defined, assigned a value, and used, but it is very difficult to know without an automatic tool.
  4. Although object-oriented techniques bring many advanced features to software development, there are something hard to do such as how to locate an overloaded function called among many functions with the same name.

Panorama's solution

  1. Generates current and accurate documents through system structure/class/function/complexity analysis of software systems, and makes the information obtained on-line accessible to the software engineers.
  2. Generates high-level class inheritance charts, function call graphs, program hierarchy trees, and low-level detailed procedural logic diagrams and control flow diagrams directly from source code, inks the generated high-level charts/trees to the low-level diagrams together so the engineers can click a mouse button on a module's name in the high-level charts/trees to read the corresponding low-level code diagrammed immediately to make software systems much easy to read and understand.
  3. Helps the engineers easily perform detailed code inspection and walk-though using the diagrammed code with the click-to-jump capability through active numbers on which when the engineer click a mouse button the diagram display will jump from a function call statement to the called function, or from a "goto" statement to the corresponding label, also automates the global variable and static variable analysis, and lists where a global/static variable defined, changed, and used to help the engineers have a deep understanding of global/static variables
  4. Makes an Objected-Oriented system much easy to understand by extending the click-to-jump capability: just click a mouse button to let the diagram display jump from a class instance to the class constructor, or from a overloading function call statement to the overloaded function exactly called. Panorama also allows the engineers to extend the click-to-jump capability: they can add marks (comments) anywhere in the diagrammed code so that the diagram display can jump to the corresponding locations easily when they click on the mark in the mark list.

Incremental test ordering for unit and system integration testing

Every software system needs to be thoroughly and systematically tested. However, because of pressing schedules and lack of good tools, testing is often ad hoc. This means that costly problems may not be discovered and corrected in time. Using Panorama C/C++ can for systematic testing can help solve the problem.

Problems

  1. Software unit testing and integration testing are often done randomly without top-down or bottom-up order. So, as an example, when testing a function that calls two functions that are untested or call other untested functions, the user must design and use stub functions to replace the two functions. So drivers and stub modules are needed to replace the callers or called modules in random unit and integration testing.
  2. Designing and using drivers (without top-down testing order) or stub functions (without bottom-up test order) not only slows down the test process, but also needs extra cost.
  3. It is not real case testing when using stub functions to replace the real functions, in unit test because stub functions will not return the exact values that should be returned from the real functions. So the test results using stub functions will not be so valuable as the real case testing. Sometimes using stub function may cause some troubles.
  4. Random order testing makes unit test and sub-system integration test be two separated processes and takes much more time.
  5. In a new software system, there may be some functions critical which and the all related functions calling and called by a critical function should be test first to reduce the system development risk. But it is very difficult to do without a bottom-up ordering tool.
  6. It is inefficient for a team to test a software system without test order, because that who should test what will be unclear, some units may be test repealed, and some may not be assigned to anybody. It is almost impossible to manually assign test order to a large system without an automatic tool. Without an order, some unused modules may also be tested.

Panorama's solution

  1. Generates a unit and integration test orders on the generated function call graph of a software system to guide the software engineers test that system better. The test order can be top-down style or bottom-up style to meet different test needs.
  2. Brings the engineers savings in designing and using drivers when using the top-down test order, or stub functions when using the bottom-up test order which is recommended by Panorama.
  3. Helps the engineers perform real case testing by following the bottom-up test order. Real case testing makes the test results much valuable and makes the system tested more reliable.
  4. Makes it possible for the engineers to combine unit testing and sub-system testing together to save their time.
  5. Allows the engineers to highlight a critical module path (a critical module and all related modules calling or called by it) and then Panorama will assign bottom-up test order to those modules only to help the engineers test those modules first before testing any un-critical modules to reduce the risk.
  6. Assists a software development team in test task assignment well through the test ordering, because several members of the team now can work in the same level perorally and use the tested modules efficiently with the test orders; frees the engineers from making the test order manually; attaches the test coverage results on the generated class inheritance charts, function call graphs to help the engineers easily know not only what functions/classes are tested, but also how good they are tested; lists the modules unused in the systems to save the time in testing those modules and help them find the potential problems: why those modules unused are put in the systems?

Multimetrics-based test complexity analysis for test planning

Software systems have become more and more powerful, but also more and more complex. Complex code is hard to read, understand, and modify; it also takes more effort to test, maintain, and retest. Panorama C/C++'s test complexity analysis can help software engineers to plan their test activity easily and accurately.

Problems

  1. Complex programs takes more effort to test. But it is hard to know how complex a program module is without a complex measurement tool.
  2. Although program control flow-based path analysis is useful for complexity analysis, most existing control flow graphs/diagrams are unstructured, use the same node notation to represent different logic, and cannot display related information (such as the source location and the execution condition of a decision).
  3. McCabe's Cyclomatic Complexity is easy to measure, but insufficient for test planning.
    It only consider the effect of branching nodes without considering the effect of conjunction nodes in the control flow graph of a program. It also cannot differentiate the amount of effort needed for different level of test coverage, such as block coverage or condition-segment coverage.
  4. The complexity analysis reports given by most tools are lists in hard-to-read textual format.
  5. Most complexity analysis tools are not object-oriented: they do not provide class complexity analysis. For better plan the testing of an object-oriented software system, however, the users need complete complexity information: both the system-level complexity information and the detailed class/function level complexity information, shown graphically.

Panorama's solution

  1. Provides both system level complexity analysis and procedure level complexity analysis to accurately measure complexity for helping engineers to plan their test activities better.
  2. Represents the results of path analysis in J-Flow, a new control flow diagram that is structured and colorful, uses different notations to represent different logic, and clearly annotated with condition of each decision and the source code locations.
  3. Helps engineers to better estimate, using test complexity metrics, the effort required for meeting different levels of test coverage requirements: provides block test complexity, branch test complexity, segment test complexity, condition-decision test complexity, and condition-segment complexity. The value of the test complexity depends on the number of instrumentation points required for recording the corresponding test coverage data.
  4. Shows the complexity analysis results in graphics, including both the high-level graphic overview of the system complexity, and the low-level graphic display of the detailed control flow of each program module using J-Flow. In the high-level, Panorama shows the complexity information in bar graphs overlaid on the generated class inheritance charts and function call graphs.
  5. Offers engineers object-oriented class complexity analysis. The high-level complexity overview shown in the class inheritance charts and function call graphs generated are linked to the low-level J-Flow diagrams automatically to provide the users with a complete understanding of the complexity of the system as well as the individual modules. The system is fully documented with analysis results in a variety of formats, including tables, bar graphs, histograms, Kiviat diagrams, or overview charts.

Test coverage analysis with makefile-driven code instrumentation

Any untested piece of code may contain fatal bugs. Software developers cannot afford to wait for users of the software system to discover them.

Problems

  1. About 50% of the development cost is spent on software testing in many companies.
  2. About 50% of the code is untested in a program "fully tested" using functional (black-box) test methods only. Structural testing is often difficult to perform.
  3. Most test coverage analysis tools provide only one or two test coverage measurement metrics, such as the basic statement or block test coverage, so the user does not have much choice.
  4. The handful of tools that offer branch test coverage analysis can only show the analysis results in hard to read textual format.
  5. Many test coverage tools can not match the dynamic test coverage results to the original source code locations: the tools can tell the user that there are some untested segments in the user's program but cannot tell where they can be found in the source code.
  6. To use most test coverage analysis tools, the user must manually prepare an input-bin file for each project to tell the tools what files need to analyze with what compiler options. The few tools that can use makefiles to generate the input-bin files can only handle simple makefiles (no nested make commands or direct compiling commands).
  7. Most test coverage analysis tools provide only the accumulated test coverage results but not the last-run-only test coverage result, so it is hard to evaluate the contribution of each test case.
  8. Most test coverage analysis tools do not provide frequency analysis, which can help users pinpoint problems.
  9. The test coverage analysis provided by most test coverage tools is procedure-based, rather than class-based.

Panorama's solution

  1. Reduces the cost of software testing by bringing automation to many test tasks from test planning to test result review and documentation.
  2. Enables test engineers perform structural (white-box) testing easily through path analysis, complexity analysis, control flow diagramming, test coverage analysis, etc.
  3. Provides engineers with the most comprehensive test coverage analysis capability including statement/block/branch/segment/condition-decision/condition-segment test coverage to meet different testing needs from low cost to very high quality.
  4. Shows the analysis results in graphics: displays both the test coverage overview using bar graphs overlaid on the generated system overview graphs, and the detailed segment and condition coverage result shown in structured J-Diagrams and J-Flow diagrams with the untested elements highlighted.
  5. Automatically matches the dynamic test coverage results to the original source code locations.
  6. Automates test coverage analysis from input to output; directly uses the original makefile of a project to generate the input-bin file.
  7. Offers both accumulated test coverage results and last-run-only test coverage results for testing engineers to easily review the total contribution of a set of test cases (test data) and the contribution of each test case.
  8. Performs both code test coverage analysis and code execution frequency analysis at the same time, and shows both results on the generated J-Diagrams and J-Flow diagrams.
  9. Calculates the test coverage analysis results for classes and functions for software engineers to better test an object-oriented software system.

Efficient un-tested path/segment testing and re-testing

Problems

  1. It is difficult to know what code segments are untested after a users' program running without an automatic tool, particularly to the "invisible" segments such as a "if" statement without "else" part and the execution condition of the "if" statement is always satisfied.
  2. Although there are some test coverage analysis tools which can identify whether there are some code segments untested in a program module, they can report the results in hard-to-read textual format only.
  3. Some tools can report the untested segments in graphics, but can not match the dynamic untested segments/branches to the locations of the original source code, because those tools do the code instrumentation after preprocessing using other vendor's preprocessor so there is no information about the location of the original source code of each segment after preprocessing.
  4. Even there are a few tools which can match the dynamic test coverage results to the locations of source code, those diagrams are static without ability to highlight the untested segments on-line.
  5. Almost all existing test coverage analysis tools do not allow the user to select an untested segment on the generated control flow diagram to highlight one or more paths passing through that segment and list the corresponding test conditions of the paths automatically. So for testing an untested segment the user must manually identify what paths passing through that segment, and the test conditions of the paths. It is a time consuming task.
  6. For re-testing any code segment after code modification, the user must run a lot of the original test cases again because the users do not know what test cases can be used to test the modified code segments without a test case and code correspondence analysis tool.

Panorama's solution

  1. Pinpoints the untested code segments for you automatically after your program running, including the "invisible" segments.
  2. Shows the test coverage analysis results in graphics in both high-level class inheritance charts and function call graphs using bar graphs overlaid on each module-box, and low-level detailed results using J-diagrams and J-Flow diagrams with capability to show the code execution frequency too.
  3. Matches the dynamic test coverage results to the locations of the original source code automatically using ISA's own preprocessor specially designed. This capability is very important to the users in finding potential problems and efficient test data design.
  4. Allows you to select whether to highlight the untested segments or not on-line in the generated procedural logic diagrams and the control flow diagrams.
  5. Provides you the capability to allow you select any untested segment to highlight one or more paths passing through that segment dynamically, and automatically lists the test conditions of each path to help you design the corresponding test data easily. More efficiently, the smart Panorama will automatically selects and shows you a path with the most untested segments and the test conditions to help you test the untested segments as more as possible using only one of the test data.
  6. Offers you the capability of test data to code correspondence analysis and code to test data correspondence analysis, so for re-testing a segment after modification, Panorama can help you select only one test case to re-test it easily.

Time-saving module-level re-testing

Problems

  1. It is hard to know what modules are unused and what modules are untested without static and dynamic analysis tools.
  2. Although there are some test coverage analysis tools which can report what modules are untested, the reports are written in hard-to-read textual format.
  3. All existing procedure-base test coverage analysis tools do not provide the capability to identify the code test coverage of a class and a class with all other classes inherited by it.
  4. Almost all existing test coverage analysis tools do not assist the users in testing the untested modules.
  5. After a tested module is modified, the users do not know what test data can be used to re-test it without a test data and module correspondence analysis tool, so the users need to re test it using a lot of test data again.
  6. It is more difficult to know what test data should be used after a class is modified without a class and test data correspondence analysis tool.

Panorama's solution

  1. Provides you the capability to analyze your systems statically and dynamically, reports what modules are unused and what module are untested automatically.
  2. Shows the analysis results in easy-to-read bar graphs overlaid on the generated overview charts and detailed procedural logic diagrams and control flow diagrams.
  3. Offers you both the procedure-based and class-based test coverage analysis capability, reports both the test coverage of a class and the test coverage of a class with all classes inherited by it.
  4. Assists you in testing the untested modules easy with the recommended steps: a) Use Panorama to generate a class inheritance chart or function call graph with test coverage analysis data. Those charts are leveled in a top-down order. b) Following the top-down order, select an untested module in the highest level with untested modules to highlight all modules calling it, then chose a shortest module path (with minimal modules) form the top level to it. c) Click a mouse button on the module nearest to it form the chosen path to view the module's J-Diagram with test coverage data, then use the FIND function to locate the first function call statement calling that untested module, and remember the number of the corresponding segment. d) Click a mouse button again on the module to view the J-Flow diagram with test coverage data, then select the corresponding segment to highlight a test path and the corresponding test conditions of the path which will help you design the corresponding test data easy to test that un
  5. Brings you great savings in re-test a class/function after it is modified: Panorama pinpoint you what test data can be used to test that class/function in graphics through test data and module correspondence analysis.

Cost-effective and automatic system-level re-testing

Problems

  1. System level software testing is very expensive which need to design and use many different test data (test cases).
  2. Software systems often need to be changed to add new features or to fix bugs. But software systems are hard to change: a) when the users want to change a module, they must remember in what file that module is written in, and in what directory the corresponding file is stored; b) changing one module often introduces inconsistency to other modules.
  3. Re-testing a system after some modules are changed is time-consuming: the user must to re-run almost all their test data again even many of them just duplicate the test results obtained before. Although play-back tools can automate the process of re-testing, they will re-run the system using all test data the users used before because they cannot identify which one is useful. To efficiently re-test a system, the users need a test data (or test case) minimization tool which can automatically selects a minimal set of test data from the all test data and guarantees to obtain the same segment-level test coverage result. But test data minimization is hard to realize because
    1. There have been many existing test data script files in different formats. A test data minimization tool should be able to use them.
    2. Different companies may want to use different formats in the design of their test data. For instance, some companies may want to use an empty line as the separator between two test data, some companies may want to use a semicolon (";")
    3. There are many problems to be solved for the design of a test data minimization tool such as how to store the test results, how to compare the contributions of test data, and how to select a minimal set of test data.

Panorama's solution

  1. Provides a framework to help you design your test data (test case) script files easy.
  2. Assists you in making changes of your systems easy through the Module Editor to allow you click a mouse button on a module-box to edit the code directly in the generated over view charts without knowing in what file and what directory that module is. After you modify or add some new modules, re-generates the overview charts and allow you highlight all the related modules or list all the detailed locations of the related module calls statements to help you ensure the consistency between the related modules.
  3. Brings you great savings in system level software re-testing, provides you the capability of test data efficiency analysis, and the capability of test data minimization:
    1. offers a utility to assist you in using your existing test data script files easily.
    2. existing test data script files easily.

      Panorama's Object-Oriented test data minimization technique is the key to help you reduce your software testing cost. Application results show that within a huge test data sets, only about 10% to 15% of them are useful, others just duplicate the test results obtained before, particularly after reaching 50% to 60% segment test coverage level, almost all test data generated randomly are useless.

Object-Oriented software quality measurement

Problems

  1. It is hard to establish and use a quality standard for a company because without an automatic tool the user can not easily select what metrics to be use and what acceptable bounds to set.
  2. Collecting the quality data of a software system is difficult. In many companies, this task is done manually, takes a lot of time. Often the collected quality information is out of date and incorrect.
  3. The analysis and review of software quality information can be time consuming, because often the obtained information about a software quality is too much but not on-line accessible to the users without automatic quality measurement and report tools.
  4. Most quality measurement tools available on the market are function-based. It is virtually impossible to use those function-based quality measurement tools to measure an Object-Oriented software system precisely. For example, for unit testing an Object-Oriented system, class is the most important unit. But a function-based quality measurement tool will only report the results by function rather than by class.
  5. Measuring the quality of an Object-Oriented software system is much more difficult than measuring a traditional software system. For instance, the complexity and test coverage of a class need to be determined indirectly; a class may be derived from many base classes which also need to be counted.
  6. There are inadequate class-based metrics for measuring an Object-Oriented software system quality including the testability, maintainability, reusability, understandability, productivity, etc.
  7. It is time consuming to re-measure the quality of an entire system after one or some source files are modified.
  8. Most provide only hard-to-read reports in textual format

Panorama's solution

  1. Provides a framework to help you set your company quality standard easily, allows you to select the metrics and the required minimal and maximal values directly, and then saves your selection for further use.
  2. Automates the collection of quality data of your systems quickly, makes the information collected be current and accurate.
  3. Analyzes the quality information collected from your existing source code automatically according to the metrics and the required minimal and maximal values you set.
  4. Provides both the traditional function-based quality measurement capability and class/object-based software quality measurement capability with emphasizing on the later.
  5. Uses new approach o determine the quality results of a class indirectly, but shows the results directly.
  6. Defines and uses many useful Object-Oriented metrics (recommended by OO specialists) to help you measuring your software systems:
  7. Re-measures your system quality quickly for you after one or some source files are modified using an incremental data technique.
  8. Shows or prints the results in colorful weighted bar charts, Histograms, and Kiviat diagrams.

Re-engineering support

System structure analysis

Problems

  1. It is hard to understand the system structure of a software system, particularly a large and complex one with many classes and functions.
  2. A system's design documents and diagrams drawn using graphic editors are often incomplete and out of date.
  3. Although there are some system structure analysis tools available on the market, most of them are function-based, hard to be used in the structure analysis of an Object-Oriented system.
  4. Most system structure analysis tools cannot generate a chart or diagram for an entire system rather than many small pieces.
  5. The generated system level charts and diagrams by most system structure analysis tools are hard to read: some of them are line-style rather than box-style, the layouts of the charts generated by some structure analysis tools are poor with many connection lines directly passing through module-boxes.
  6. The system level structure charts and diagrams generated by almost all existing system structure analysis tools are static, so the users can see them but can not work with them directly. For example, when the users want to know what modules may be effected after a specified module is modified, the users can not point the specified module-box to highlight all the modules calling it or called by it using the static graphic representation techniques.
  7. There is on capability to link the generated system level structure charts and diagrams to the module level detailed code or the logic diagrams of the code with most system structure analysis tools.
  8. Almost all existing system structure analysis tools can not directly show the related information such as the complexity and test coverage of a module on the generated system level structure charts and diagrams.

Panorama's solution

  1. Facilitates understanding of the structure of a small to very large system through automatic system structure analysis.
  2. Generates current and most complete charts, diagrams, and other documents about a system structure directly form the source code.
  3. Brings engineers the most powerful capability to analyze the system structure of an Object-Oriented system, generates not only function call graphs, but also the class inheritance charts, class-function coupling charts, etc.
  4. Enables engineers to view the system structure chars and diagrams of an entire system or any sub-system easily with the capability to show a reduced view of a very large system.
  5. Employs Jay Xiong's (the founder of ISA) VLSI layout algorithms in the layout design of system structure chars and diagrams -- no connection line passes though any module-box-- making the generated charts and diagrams much easier to read and understand.
  6. Uses the advanced Dynamic Graphic Representation Technique to generate system level charts and diagrams, so software engineers can view the charts and diagrams, and also work with them: highlight a module with all the related modules, select a module as the new root to generate next level sub-charts, assign a bottom-up or top-down testing order to all modules or only the modules highlighted, etc.
  7. Links the generated system level charts and diagrams to the module level logic diagrams and control flow diagrams automatically. Just point to a module-box in the generated system level charts and diagrams to view directly the corresponding low level diagrams.
  8. Allows you to show or print system level structure charts with the modules' related information such as the complexity and the test coverage using bar graphs overlaid.

System class/procedure analysis

Problems

  1. Most system procedure analysis tools are function-based, so they cannot analyze classes of an Object-Oriented software system. But the capability for analyzing classes is essential to a procedure analysis of an Object-Oriented software system because classes play the key role in an Object-Oriented software product.
  2. Many procedure analysis tools are command-line-driven tools without Motif/Openlook graphic user interface, hard to use.
  3. Only some very simple reports such as function cross reference can be generated by most procedure analysis tools. But for getting a deep understanding of a software system, the users need much more detailed information about a file/class/function.
  4. The information extracted by most procedure analysis tools is not detailed enough such as that in the function cross reference reports generated by most procedure analysis tools, there is only the information telling the users a function is called by how many functions and the names of the callers without the detailed information (in what file at what source line a function is called). So when a function is modified, the users do not know what detailed source code locations the modification may introduces inconsistency to with the simple reports generated by most procedure analysis tools.
  5. There is a lack of flexibility with most procedure analysis tools so the users can get either the results of an entire system or nothing. But in many cases the users may want to have only the information about a subset of a system.
  6. The information obtained by most procedure analysis tools is not on-line accessible to the users.
  7. The results obtained by most procedure analysis tools are shown in textual format only without graphics, hard to read and understand.

Panorama's solution

  1. Provides you the most comprehensive class/function analysis capability to help you understand your systems in deep, Particularly, the capability of class analysis. For each class, Panorama reports you the information of the location, the constructor and destructor, the data members and function members, the nested classes, the base classes and the derived classes, the friend classes and the friend functions, the virtual functions and overloaded functions, the global instances, the complexity, the test coverage, etc.
  2. Enables you to run Panorama for class/function analysis through its Motif/Openlook graphic user interface or command-lines.
  3. Brings you the most strongest analysis capability to generate a lot of useful reports. For example, for each function Panorama reports the information of the prototype, the location, the compactness analysis results, how many global variables used, how many functions calling it and called by it, how many labels used and how many labels defined but not used and the corresponding "goto" locations, the complexity, the test coverage, the performance, etc.
  4. Reports the information in detail. For example, for the function cross reference, Panorama not only tells you how many functions call it, but also the detailed source code locations of the corresponding function call statements. It helps to make code modification easier and safer.
  5. Allows to select either to analyze the whole system or only a subset of a system. easily.
  6. Makes the information obtained in the class/function analysis on-line accessible for you.
  7. Shows and prints out the analysis results in not only textual format, but also in alpha-beta-ordered bar charts and value-ordered bar charts as many as possible to help you read and understand them easy.

System procedural logic analysis and diagramming

Problems

  1. Research has shown that about 38% of a programmer's time is spent in understanding a software system because code written in multiple files in textual format is hard to read.
  2. System procedural logic analysis and diagramming plays an important role in understanding a system in depth, but it is very difficult to perform manually without a tool.
  3. There have been a few procedural logic analysis tools available on the market, but almost all of them provide simple diagramming capability to generate Action Diagram only which is in line-style format rather than block-style format, can not separate the condition part and the execution part of a decision. So Action Diagram is not suitable for complete procedural logic analysis.
  4. The procedural logic diagrams generated by almost all procedural logic analysis and diagramming tools are in file scope, not program scope. So when the users finish reading the logic diagram of one file, they must manually close it, then open the diagram of a new file.
  5. The procedural logic diagrams generated by almost all procedural logic analysis tools are static: the user can see them but can not work with them. Static diagrams need to use a lot of space to store, can not be linked with the high-level program tree or other system overview charts dynamically, can not dynamically display test coverage data, and the diagram display can not jump from a function call statement to the location of the called function automatically. The users can not use a mouse to point to a "#include" statement on a diagram to directly view the diagram of the head file.
  6. Almost all existing procedural logic analysis and diagramming tools do not offer Object-Oriented logic analysis and diagramming capability, there is even no a set of diagram notations for representing a class with those tools.

Panorama's solution

  1. Helps you understand your software systems quickly through procedural logic analysis and logic diagramming because the code diagrammed is much easy to read and understand.
  2. Brings you full automation of diagramming, generates the logic diagrams of your systems directly from your source code.
  3. Generates both the Action Plus diagrams and J-Diagrams to represent your program procedural logic. The structured J-Diagram is in block-style, uses different notations to represent different logic, and uses different notations to separate the condition part and the execution part of a decision statement. The code execution frequency and code test coverage data can be added to the J-Diagrams, and the untested code segments and the outcomes of any conditions of a decision statement can be highlighted.
  4. Provides you the logic diagrams of your systems in all scopes from an entire system to an individual function. For an entire system, you can scroll the diagrams through the whole system without the operation of closing and opening files by yourself.
  5. Activates the diagrams generated using the advanced Dynamic Graphic Representation Technique, generates the logic diagrams in any levels dynamically and rapidly using the information stored in Panorama's incremental repository. More importantly, you can point to a function call statement to let the diagram display jump from the statement to the location of the called function, from a class instance to the class constructor, or from a "#include" statement to the diagram of the head file.
  6. Offers you Object-Oriented logic analysis capability, offers special notations for representing classes, linking the class diagrams to the class inheritance charts, and much more.

System control flow and cyclomatic complexity analysis

Problems

  1. System control flow and cyclomatic complexity analysis play an importance role in code understanding, testability and maintainability review, and system improvement. But control flow analysis and complexity analysis are hard to perform without an automatic tool.
  2. Most control flow analysis tools available on the market generate unstructured control flow diagrams which are hard to read and understand
  3. The control flow diagrams generated by most tools are in file-scope only. Without program scope and function scope, those file-scope control flow diagram can not be linked with the high level program tree and other system overview charts dynamically, so the users can not read through the entire system control flow diagram of a complete system, or view the control flow of an individual function from the program tree or other system overview charts.
  4. Important data such as code execution frequency and test coverage can not be attached to the control flow diagrams generated by most tools.
  5. The control flow diagrams generated by most tools are static, so the users can see them but not work with them dynamically. For example, the users can not point to a segment on a control flow diagram to let the diagram display highlight one or more paths passing through that s segment and list their test conditions.
  6. Many cyclomatic complexity analysis tools based on control flow analysis generate reports in textual format only. Although there also are some tools providing graphic representation capability of complexity, the charts or diagrams used are also static: the users can not select a module on the complexity overview chart of a system to highlight all the related modules and view their complexity only.
  7. Most complexity analysis tools do not provide the capability for class complexity analysis.

Panorama's solution

  1. Brings you full automation of control flow and cyclomatic complexity analysis.
  2. Generates J-Flow diagrams to represent the control flow of your systems. The J-Flow diagram is structured, uses different notations to represent different logic with capability to show the condition of a decision and the locations of the corresponding source code.
  3. Provides you multi-level control flow diagramming capability: generates the control flow diagram of a complete system, a single source file, or an individual function to meet different needs. The generated J-Flow diagrams can be linked with program tree, function call graphs, and class inheritance charts dynamically to help you read an entire system control flow diagram or an individual class/function's control flow diagram easily from the generated program trees or other overview charts directly.
  4. Shows the control flow diagrams with many useful data attached such as the code execution frequency and code test coverage analysis.
  5. Activate the generated J-Flow diagram using the advanced Dynamic Graphic Representation Technique, so you can click a mouse button on a segment shown in the generated J-Flow diagram to highlight one or more paths passing through it with the path test conditions, or let the diagram display jump from the linked program tree to the location of a function your interested in.
  6. Represents the complexity analysis results of your systems dynamically in many graphic ways, including color charts, Kiviat diagrams, Histograms, bar graphs overlaid on the generated class inheritance charts or function call graphs for whole system or any sub-system.
  7. Offers you the capability for Object-Oriented system complexity analysis including the complexity analysis of a single class and a class with all classes it inherits.

System data analysis

Problems

  1. It is very difficult for the users to understand a system deeply without knowing the behavior of the data used in the system, particularly the global data because they may be defined, used, and changed in many different files.
  2. Many bugs, errors, and potential problems are come from misuse of data. But it is hard to find a data problem without an automatic data analysis tool.
  3. Although it is recommended to use global and static variables in an Object-Oriented software system as less as possible, there are still some global and static variables used in a C++ program particularly in those programs with partial C code. But most re-engineering tools do not provide the capability to analyze data, and some Object-Oriented re-engineering tools only provide the capability to report the data members of a class without analyzing the global and static variables.
  4. Although there are a few data analysis tools available on the market, most of them only provide the reports of the data analysis in program level without reports in file, class, and function levels.
  5. The data information extracted by some analysis tools is not on-line accessible, hard to find and use.The data information extracted by some analysis tools is not on-line accessible, hard to find and use.
  6. Often there is a need to modify the data of a software system because of adding new features or new functions. But the modification of global data in a software system is risky because it often affect other parts of the code. So before the users modify a global variable, they must know where the variable is defined, used, and changed.
  7. The lack of current and accurate data documents becomes one of the major problems why a software system is so difficult and expensive to maintain.

Panorama's solution

  1. Helps you understand your software systems deeply by providing the capability of data analysis and structure/class/function/complexity analysis.
  2. Assists you in finding data errors much easy through detailed data analysis reports and unused data reports.
  3. Offers you not only the capability for class data member analysis for an Object-Oriented software systems, but also the capability for the global and static data analysis to help you easy understand your systems written in pure C++ code or in mixed C++ and C code.
  4. Provides you multi-level data analysis capability, reports you not only how many global variables defined, used, and changed in your software systems, but also reports you how many global variables imported to and exported from a source file, how many global and static variables used and changed in a class, and how many global and static variables used and changed in a function to meet your different needs.
  5. Enables you to access the obtained data information on-line through the active index, helps you locate the global and static data your interested in easy by listing them an alpha-beta order with a FIND utility.
  6. Makes it possible for you to modify the data of your systems safely by providing very detailed information about data, reports you where a global or static variable is defined, used, and changed with the detailed source code locations, so before you modify a global or static variable, you know where the modification may affect c already.
  7. Generates and prints current, accurate, and multi-level data documents for you to help you maintain your software systems much easier.

System performance analysis

Problems

  1. There are often performance bottle-necks in a software system: most of the run time is spent in a few classes/functions. To find the potential problems and improving the performance of a system, the users need to know where are those bottle-necks of the system and then remove them by modifying the code of those classes/functions (such as using new algorithm or using assemble language). But without an automatic performance and code execution frequency analysis tool, it is very difficult to do.
  2. Although most C++/C compilers provide the capability of performance analysis as an option, the reports are written in textual format, hard to read.
  3. There are only function-based performance analysis capabilities with almost all compilers without the capability for class-based performance analysis.
  4. Procedure level and segment level code execution frequency analysis play an important role in both performance improvement and logic error debugging, but almost all C++/C compilers only provide only the capability of procedure execution frequency.
  5. There have been a few test coverage analysis tools providing the capability for code execution frequency analysis, but the capability is limited in statement or block level rather than branch/segment level, so the results are not accurate enough. The results given by most code frequency analysis tools are code-writing-style dependent: those tools often report wrong results if the condition part and the execution part of a decision statement is written at the same source line, or a loop statement is written at the same source line with a "case" statement.
  6. The results of code execution frequency analysis by most tools can not be directly shown with the procedural logic diagrams or control flow diagrams in most frequency analysis tools.

Panorama's solution

  1. Pinpoints the performance bottle-necks of your software systems for you automatically through performance analysis and code execution analysis to help you improve your system performance.
  2. Cooperates with your system C++/C compilers to analyze the performance data; shows the results in bar graphs overlaid on each module-box in Panorama's function call graph, shows the time spent in each module along with the execution frequencies. The longer the bar, the long the run time spent on the module, so you can identify the bottle-neck quickly.
  3. Offers you the capability for both function-based performance analysis and class-based performance analysis -- important for reviewing the efficiency and reusability of a class.
  4. Provides you not only the capability for procedure execution frequency analysis but also the capability for detailed code execution frequency analysis which is more useful in helping you locate the second-level bottle-necks and find out potential problems why most of the run time is spent on those code locations, such as that two big loops should be written separately, but have been written nestled.
  5. Brings you the most comprehensive code execution frequency analysis capability -- including block execution frequency analysis, branch execution frequency analysis, and segment execution frequency. The analysis results generated by Panorama are coding-style independent. Panorama will report correct code execution frequency results whether the code is written all in one line or in many separate source lines.
  6. Shows the frequency analysis results not only in overview charts, but also in the program logic diagram and control flow diagrams.

On-line accessible document book and report generation

Problems

  1. Many programmers dream of a software tool that can document their systems automatically, because writing documents takes time, and the documents need to be updated again and again.
  2. Many software systems are not documented well, particularly in system physical design level and program level. In some systems the only document in program level is the source code list. It is why a software system is so difficult to maintain.
  3. Although in some software systems there are limited documents including physic design level and program-level documents, those documents are often out of date, do not correspond to the code.
  4. In many systems the documents were written in paper, the information included in the documents is not on-line accessible. Although there are some tools which can generate documents from users' source code and show them on the computer screen, the index of the documents is not active so the users can not pinpoint to a document index to let the report display jump from to the corresponding report.
  5. Many documents generated by most tools are textual tables, hard to read and use.
  6. Most software document tools generate function-based reports only, there is no any report about classes. But in an Object-Oriented software system classes play the key role, so the capability to document classes is essential to a document tool.
  7. Many document tools provide only some simple reports, most of the reports are come from the system static analysis. In many cases there is no documents about data and dynamic characters.
  8. Often the database of a document tools is not incremental, so that when the user changes a file all other files in the same project must be re-analyzed again to get updated documents.

Panorama's solution

  1. Realizes software engineers' dream to automatically document their software system.
  2. Makes your systems much easy to maintain by not only writing document in system level, but also in file-level and class/function level.
  3. Generates the documents directly from your source code, so the documents are current and accurate, do correspond to the code to help you understand your systems much better.
  4. Makes the information stored in the documents on-line accessible for you. You can read through it page by page under your control, or point to a index to let the document display jump to the corresponding document location automatically to save your time.
  5. Shows the documents not only in textual tables, but also in graphic charts as more as possible to make them much easy to read and use.
  6. Provides you various reports to document you Object-Oriented systems, including both function-based reports and class-based reports such as the reports of data members, function members, base classes, derived classes, global data used, virtual functions and overloaded functions, friend classes and friend functions, compactness, complexity, run time, and test coverage of a class.
  7. Brings the engineers complete set of more than 150 different reports to document an entire systems through system structure analysis, static class/function analysis, data analysis, and dynamic performance and test coverage analysis.
  8. Updates the documents of a system for the engineers incrementally: after one or some source files are modified, only those files need to be re-analyzed to update your documents. automatically.

Other applications

Project management

Problems

  1. Productivity measurement is difficult to do manually. The software managers can get the information about how many lines/words of their systems using system commands, but for precisely measuring the productivity and maintainability of their systems, they need more information such as the percentage of blank lines and comment lines in a system and an individual module.
  2. Project development progress is much difficult to measure without an automatic tool, because the managers need to know not only how many modules completed on time since a given date and how many modules are finished by a group or an individual, but also need the more detailed information about those modules such as the code complexity and test coverage.
  3. The information reported to the managers about the productivity and progress of a system development is often out of date. Software managers need the first-hand information rather than second hand information. But most schedule management tools available on the market are too simple which can help the managers draw very nice schedule charts but can not help them evaluate the system maintainability and quality. Only considering the progress about the system development schedule without knowing the maintainability and quality will mislead the managers making decision and cause problems later. A system combining the capability of system quality analysis and the capability of system management is deserved.
  4. Most software quality measurement tools are much difficult to use than schedule management tools. The lack of a software tool which provides the capability of system quality analysis and the capability of system development productivity and progress management together and is easy to use as a schedule management tool makes software managers in trouble.

Panorama's solution

  1. Helps software managers measure the productivity of their development team precisely by providing them the capability of multi-level compactness analysis including system/file/class/function compactness analysis, reports them not only how many source lines in a system/file/class/function, but also the percentage of blank and comment lines.
  2. Provides managers the capability to measure their project development progress with quality analysis, allows them to highlight all modules completed after a given date or by a group/ individual directly on the generated class inheritance charts, and function call graphs with the related quality information shown in bar graphs overlaid on each class/function box, such as the size, complexity, performance data, and code test coverage.
  3. Combines the capability of software system quality analysis and the capability of system development management together, makes the information provided to the managers about their productivity and project development progress with the quality data always be current and accurate because it is the first- hand information come directly from the source code. With the internal incremental repositories, Panorama automatically updates the related information when their systems are modified.
  4. Makes Panorama itself be easy to use as a schedule management tool through its Motif/Openlook graphic user interface and the full automation of software analysis and graphic result representation from input to output. From input, the only thing managers need to do is giving Panorama the name of a project makefile to built the information repository. In the output what managers need to do is to tell Panorama what kind of information and in what kind of format they want to have. The on-line HELP utility with active cross reference makes the operation much easier.

New team member training

Problems

  1. Training new members of a development team is expensive because it takes a lot of time for the project managers and software engineers to prepare the training material about the software system they are working on, and to teach the new members. It is why sometimes the new member training may delay the development schedule of a project being developed by the team.
  2. It often takes too long period of time for the new members to be able to begin work with the system, because the new member must have general understanding of the whole system, and deep understanding of some source code and global data related to the tasks assigned to them. Often the materials given to the new members do not correspond to the code. So those materials are not useful for them to learn the system, and sometimes may bring the new members confusion about how the system works.
  3. Letting the new members learn a software system by themselves without a helpful tool often makes them shaking because a software system may be very complex and the new members may even have no idea where should they begin to learn.
  4. Learning an Object-Oriented software system is quit different from a traditional function-based system. Often the size of a program written in the C++ programming language after preprocess can be twenty times bigger than the size of the original source code because many head files are involved and a lot of classes are used or indirectly reused from the library. Without knowing the behavior of classes used in a system though an automatic tool, the new members can not understand an OO system in depth.

Panorama's solution

  1. Reduces the cost in training new members of a software development team greatly by freeing the designers and software engineers from preparing the training materials because Panorama provides the capability of the most comprehensive static and dynamic analysis of the system to extract various information and document the system automatically, and makes the information extracted on-line accessible to the new members, saves a lot of the designers and engineers' time from teaching the new members step by step using a lot of document materials to teach them using Panorama to get and use the information on-line (usually it only takes one day of an engineer).
  2. Shortens the training time to make the new members be able to begin work on the tasks assigned to them by providing current and accurate various system overview charts and diagrams (including the data structures, class inheritance charts, function call graphs, and program trees), the detailed reports of global/static data analysis, and the detailed program logic diagrams and control flow diagrams of the source code to help them have general understanding of the system and deep understanding of the code related to their tasks quickly.
  3. Makes it easy for the new members of a team to train themselves because the ease of use of Panorama with its Motif/Openlook GUI interface, the capability of dynamically and graphically representing a system from top-level down to detailed code, and the capability of linking different level charts and diagrams together.
  4. Proves both capabilities of function-based. analysis and diagramming, and class-based analysis and diagramming to make an OO system also easy to understand in depth.

Customized system explanation and acceptance review

Problems

  1. It is difficult to describe a customized system to the customer and make him satisfied with the system the customer requested. It takes a lot of developers' time to prepare the documents, and needs many people from the managers, designers, and programmers get involved. It needs to provide a complete set of documents about the system structure design, the static characters and dynamic characters including the complexity, maintainability, performance, reliability, and much more. It is almost impossible to complete all of the system documents manually without automatic tools.
  2. Ensuring consistency between the documents and the source code is very difficult because the design documents are often done manually using graphic editors by designers, but the code is written using C/C++ programming language by programmers who often find there is a need to modify the system structure by adding new function calls or deleting some function calls.
  3. Most document tools generate function-based documents only without the capability to generate class-based documents, so those tools are hard to use to document an Object-Oriented system.
  4. Often the acceptance process of a customized system takes long period of time to complete because almost all document tools available on the market generate static documents only which need a lot of disk space to store, take a lot of time to locate the required information, and only tell the customers what have done but not what the customers can do with the documents (not only with the source code), and often are not on-line accessible. So the customer needs to have a lot of people to read and analyze those documents and the code before they can make a decision to accept the system and they believe that they can maintain the system.

Panorama's solution

  1. Makes it easy to describe a customized system to the customer by generating multi-level documents automatically though the analysis of system structure/class/function/data/complexity/performance/test coverage.
  2. Ensures consistency between the various system documents and the source code because those documents are all come directly from the source code, including the generated class inheritance charts, function call graphs, program trees of an entire system or any sub-systems, the multi-level cross references, the system static and dynamic analysis and test reports, etc.
  3. Offers the system developers the capability of Object-Oriented system analysis, generates not only function-based charts and reports, but also class/object-based various charts and reports which are more useful for describing a customized system developed using C++.
  4. Speeds up the system acceptance process by making the system much easy to understand and maintain using the Dynamic Graphic Representation Technique. INSTEAD OF PROVIDING HUGE STATIC DECUMENTS TO THE CUSTOMER, the developer can PROVIDE THE SYSTEM REPOSITORY WITH AN EXTRAL LICENSE OF Panorama to the customer, so the customer can review and verify the system by themselves on-line and visually. The size of the repository will be 1/10 to 1/100 smaller than the corresponding static document materials depending on how detailed the information provided, the more detailed the better the repository used with Panorama. For example, to show what function may be affected by modifying each function in a system with thousand functions, many static pictures are needed using static graphic representation technique, but only one active function call graph using the dynamic graphic representation technique with the capability to highlight each function and all related functions on-line.

back to Table of Contents