text:
US8146055B2 - Generating sequence diagrams using call trees - Google Patents
Generating sequence diagrams using call trees Download PDF
call tree
Kapil Bhandari
Divya Bharti
Kallol Pal
230000003068 static Effects 0 abstract claims description 35
239000000047 products Substances 0 claims description 32
238000003860 storage Methods 0 claims description 24
238000004590 computer program Methods 0 claims description 17
230000000694 effects Effects 0 claims description 5
150000001875 compounds Chemical class 0 claims description 4
238000009740 moulding (composite fabrication) Methods 0 claims description 3
230000002517 constrictor Effects 0 description 1
G06F8/70—Software maintenance or management
G06F8/74—Reverse engineering; Extracting design information from source code
A software tool is provided to analyze static source code. Source Code files are selected to define the project work space. A class and a method in the class are selected from said selected source code files. The tool generates a Call Tree as an ordered recursive sequence of all method calls in different classes or their instances that are invoked by said selected method in said selected class. A Sequence Diagram is generated from said Call Tree. The tool remembers all updates to the Call Tree used to generate the Sequence Diagram. This information is used when a generated Sequence Diagram is impacted due to changes made to any source code file included in the project.
The present application is a continuation application of a parent application Ser. No. 10/937,083 and filed Sep. 9, 2004 now U.S. Pat. No. 7,506,320.
The present invention relates to a software analysis tool and, more particularly, to an integrated reverse engineering and design workproducts maintenance tool for object-oriented type programming languages, such as, Java, and the like.
2. Background and Related Art
A great variety of tools are available in the software industry to aid in developing, maintaining and updating software programs. One of the difficulties with maintaining and updating software is the ability to keep track of work products generated and determining the affected work products when a source code file that was used to generate the work products is modified. Various approaches have been used to provide tools to aid in analyzing and maintaining software and a number of these approaches are designed for object-oriented coding using sequence diagrams.
For example, the UML (Unified Modeling Language) uses sequence diagrams to capture interactions between software components, such as, objects, methods, modules, entire software applications, sub-systems, and the like. Programs, such as AQTime, employ a static profiler that does not run the application but creates a UML-style diagram that graphically represents the sequence of routine calls. Classes are shown as entities, and source-code calls between methods of different classes are treated as messages.
One of the difficulties with the AQTime tool resides in the fact that the tool is required to operate on the static executable compiled code with appropriate debug information. Since the AQTime tool operates on executable code, it has to rely entirely on the debug information in the executable files which information exists only at the level of classes.
On the other hand, tools, such as DYNO, draw sequence diagrams for a set of classes at runtime. DYNO instruments the classes for which the diagram needs to be drawn, such that, when the classes are run, the relevant data can be collected to draw the diagram. One of the difficulties with DYNO, then, is that it requires a runtime environment while working with files that need to be deployed on an application server or some such other software to be executed.
Although the use of sequence diagrams is key to work products that are used to capture the sequence of messages passed between different classes in typical applications, such use is generally limited to the low level design phase of the application development project. The reason for limiting to the low level design phase is that creating these diagrams for the first time in a project is usually not as difficult and involved as maintaining these diagrams in synch with the changes in code that happen during the later phases of a project.
Accordingly, known software analysis tools fail to provide a simple approach such as to operate directly on object oriented source code, in a reverse engineering manner, such as to identify the impacted work products when any of the source code files of an application program are modified. The ability to readily identify work products impacted by changes in some code files permits easy updating and maintenance of such products.
SUMMARY OF THE PRESENT INVENTION
In accordance with the present invention, a software tool is provided that allows for the creation of Sequence Diagrams directly from application source code. The Sequence Diagrams are used to analyze the effect of any updates and changes made to the source code file of the application program. The Sequence Diagrams are generated using call trees derived from the source code using the Code Tree Analyzer tool, in accordance with the present invention.
The Code Tree Analyzer tool operates within a defined project workspace of the application program. The project work space contains the complete paths of the source code files, such as Java source code files, that are to be analyzed to produce work products or design artifacts. Classes the user does want to include in the work products are identified in a list. The tool analyzes the source code and generates UML-compatible model files for the sequence and class diagrams, and text and rtf (rich text format) files containing the call tree. The tool remembers the work product data that have been created. This data is used later to determine the impacted products when any of the source code files in the application program are modified.
To determine impacted work products, the tool maintains a list of source code files. Each time a project is opened, this list is updated with the latest time stamps of the source code files. The tool maintains a list of work products that were created using the tool and the source code files that were used to create each work product. Once a project is opened, the tool compares the time stamps of the source code files that was saved in the previous run with the time stamps of the files in the latest run. A difference in time stamps is taken as an updated source code file. All work products that have used this source code file are marked as impacted. In addition, the impact to design artifacts that result from manual changes made to the source code files can be analyzed and updated using the tool. Thus, the Code Tree Analyzer tool provides an integrated reverse engineering and design work products maintenance arrangement for programming languages, such as, the Java Programming Language.
Accordingly, it is, an object of the present invention to provide an improved code analyzer tool.
It is a further object of the present invention to provide a code analyzer tool that is simple, fast and easy to operate.
It is yet a further object of the present invention to provide a code analyzer tool that effectively operates directly on source code.
It is still a further object of the present invention to provide a code analyzer tool that provides a way to simply identify the impact of changes in source code files of an application program on the various work product elements of the program.
It is yet still a further object of the present invention to provide a code analyzer tool that substantially reduces the effort of determining, keeping track and synchronizing the effect of changes to the source code files of an application program.
It is yet another object of the present invention to provide a code tree analyzer tool that directly analyzes application source code and produces both sequence diagrams from call trees and class diagrams, each of which are displayed and which may be modified, updated and varied.
It is still another object of the present invention to provide a code tree analyzer tool that remembers manual updates made by the user to the filtered call trees so that in later runs of the tool, when a work product, impacted by source code changes, is recreated, the tool displays these manual updates to the user and allows the user to reapply these updates to the new call tree.
FIG. 1 shows a block diagram illustrating an exemplary hardware environment which may be used to carry out the preferred embodiment of the invention.
FIG. 2 shows a Sequence Diagram derived from a Java code snippet example used to show the manner of forming a Call Tree.
FIG. 3 is a flow chart diagram representing the flow process of the base model of the Code Tree Analyzer tool, in accordance with the present invention.
FIGS. 4A-4E is a flow chart illustrating the main process of the Code Tree Analyzer tool, in accordance with the present invention.
FIG. 5 is a flow chart illustrating a process for creating a new project, as identified in the main process of FIGS. 4A-4E.
FIG. 6 is a flow chart illustrating a process for creating a new time stamps file, as identified in the main process of FIGS. 4A-4E.
FIG. 7 is a flow chart illustrating a process for creating a new data file, as identified in FIGS. 4A-4E.
FIG. 8 is a flow chart illustrating a process that acts to resolve the symbol table, as identified in FIGS. 4A-4E.
FIG. 9 is a flow chart illustrating a process for generating a Call Tree, as identified in FIGS. 4A-4E.
FIG. 10 is a flow chart illustrating a process for rendering a Sequence Diagram from the Call Tree, as identified in FIGS. 4A-4E.
FIG. 11 is a flow chart illustrating a process for rendering a Class Diagram from the Code Tree Analyzer tool.
FIG. 12 is a drawing of a screen shot showing an example of a Sequence Diagram, as rendered by the Code Tree Analyzer tool.
FIG. 13 is a drawing of a screen shot showing an example of a Class Diagram, as rendered by the Code Tree Analyzer tool.
In the following description of the preferred embodiment, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration a specific embodiment in which the application may be practiced. It is to be understood that other embodiments may be utilized and changes may be made without departing from the scope of the invention.
FIG. 1 is a block diagram illustrating an exemplary hardware environment used to implement the preferred embodiment of the invention. In this exemplary hardware environment, a computer system arrangement 1 may include a central processing unit (CPU) 3, memory 5, data storage device 7, data communications device (DCD) 9, input device 10 and display device 29. Other peripheral devices may also be included. The input device and storage device are connected to the system bus 31 through respective interface units I/F while the display device is connected to the system bus through graphics board 35. The computer system 1 may be connected locally or remotely to fixed and/or removable data storage devices, such as, storage device 7. The computer system 1 may also be connected to other computer systems 19 through DCD 9.
The present invention may be implemented using one or more computer programs that form the Code Tree Analyzer tool, which tool executes under control of the operating system (OS) 21, such as, Windows, DOS, OS/2, AIX, UNIX, MVS, etc. The stored Code Tree Analyzer tool (CTA), as represented by block 23, causes the computer system 1 to operate on stored static application source code files, as represented by block 25. The resulting work products are stored as data, shown by block 27. Thus, in accordance with the present specification, the invention may be implemented as a machine process or article of manufacture by using standard programming and/or engineering techniques to produce software, firmware, hardware or any combination thereof.
The Code Tree Analyzer, as represented by block 23, and operating system 21 are tangibly embodied or readable from a computer-readable device or media, such as memory 5, data storage device 7 and/or data communications device 9, thereby making a computer program product or article of manufacture, according to the invention. As such the term "article of manufacture" and "computer program product" as used herein are intended to encompass a computer program accessible from any computer readable device or media.
Code Tree Analyzer 25 and operating system 21 both include instructions which, when read and executed by the computer system 1, cause the computer system to perform steps to process and analyze application source code 25, in accordance with the invention. Under control of the operating system, the Code Tree Analyzer code may be loaded from any of a variety of sources into memory 5. Source code 25 to be analyzed will be described in terms of the Java programming language although, it is clear that with minor modifications, other object-oriented programming languages may also be analyzed.
In accordance with the present invention, the Code Tree Analyzer tool is built around Sequence Diagrams as a visual representation of Call Tree data structures. The Call Tree data structure is a tree structure that is created by recursively determining method calls on classes or their instances starting at a specified method in a class (as input). The following example demonstrates the process used to generate a Call Tree from Java source code in the Code Tree Analyzer tool. Although the example and the discussion is in terms of the Java programming language, it is clear that the process described is not restricted to the Java programming language and could readily be applied to other programming languages as well.
The purpose of determining the Call Tree is to form a data structure to use to derive a Sequence Diagram. The Sequence Diagram begins with a method invocation on a class. In the context of the Code Tree Analyzer tool, this has been called the "start point". A start point is a class name and method name combination from where the tool starts creating the Sequence Diagram. This is taken as one of the inputs from the user in the Code Tree Analyzer tool.
The following three Java code snippets are used as a simple example to demonstrate the process of forming a Call Tree and Sequence Diagram. Each line of the code snippets has been numbered for reference in the description.
Code Snippet 1: ClassA 1 public class ClassA { 2 3 /*The constructor for Class A */ 4 public ClassA ( ) { 5 6 } 7 8 /*A method in class A */ 9 public void method1A(String arg1) { 10 11 /* Class A creates a new instance of Class B */ 12 ClassB instClassB = new ClassB( ); 13 14 /* Class A invokes a method on Class B */ 15 instClassB.method1B( ); 16 17 /* Class A creates a new instance of Class C */ 18 ClassC instClassC = new ClassC( ); 19 20 /*Class A invokes a method on class C */ 21 instClassC.method2C( ); 22 } 23 24 /* Another method in class A */ 25 public void method2A( ) { 26 27 } 28 }
Code Snippet 2: ClassB 1 public class ClassB { 2 3 /*The constructor for Class B */ 4 public ClassB ( ) { 5 6 } 7 8 /*A method in class B */ 9 public void method1B( ) { 10 11 /* Class B invokes a method on itself */ 12 method2B( ); 13 14 /* Class B invoked another method on itself */ 15 method3B( ); 16 } 17 18 /*The method 2B */ 19 public void method2B( ) { 20 21 } 22 23 /* The method 3B */ 24 public void method3B( ) { 25 26 /* Class B Creates an instance of classC */ 27 ClassC instClassC = new ClassC( ); 28 29 /*Invoke a method on class C */ 30 instClassC.method1C( ); 31 } 32 }
Code Snippet 3: ClassC 1 public class ClassC { 2 3 /*The constructor for Class C */ 4 public ClassC ( ) { 5 6 } 7 8 /*A method in class C */ 9 public void method1C( ) { 10 11 } 12 13 /*The method 2C */ 14 public void method2C( ) { 15 16 } 17 18 /*The method 3C */ 19 public void method3C( ) { 20 21 } 22 }
The above code snippets show the source code for three Java classes. Assuming that the user wants to draw a sequence diagram beginning at the start point ClassA-method1A, the Call Tree would be derived as follows:
First determine the declaration for method1A in the class ClassA. Method method1A starts at line 9 and ends at line 22 in the code snippet 1. In the method method1A determine the methods and constructors that are invoked. In this case, the following methods and constructors are invoked.
1. The constructor of ClassB at line 12
2. The method method1B on class ClassB at line 15
3. The constructor of ClassC at line 18
4. The method method2C on class ClassC at line 21
The above represents the first iteration of the tool.
For each of the above, determine the declarations. In so doing, the following is determined.
1. The constructor ClassB starts at line 4 and ends at line 6 in Code Snippet 2
2. The method method1B of class ClassB starts at line 9 and ends at line 16 in Code Snippet 2
3. The constructor ClassC starts at line 4 and ends at line 6 in Code Snippet 3
4. The method method2C of the class ClassC starts at line 14 and ends at line 16 in Code Snippet 2
For each of the above method and constructor invocations, determine the methods and constructors invoked in them.
1. There are no methods or constructors invoked within the Constructor ClassB
2. Following are the methods and constructors invoked within the method method1B of the ClassB
2.1 The method method2B on class ClassB at line 12
3. There are no methods or constructors invoked within the Constructor ClassC
4. There are no methods or constructors invoked within the method method2C of ClassC
The above represents the second iteration of the tool.
For the items 2.1 and 2.2 above determine the declarations. In so doing the following is determined. The other items are ignored in this iteration, as they do not have any method or constructor invocations in them.
2.1 The method method2B of class ClassB starts at line 19 and ends at line 21 in Code Snippet 2.
2.2 The method method3B of the class ClassB starts at line 24 and ends at line 31 in Code Snippet 2.
For each of the above method and constructor invocations (2.1 & 2.2), determine the methods and constructors invoked in them.
2.1 There are no methods or constructors invoked within the method method2B of the class ClassB
2.2 Following are the methods and constructors invoked within the method method3B of the ClassB
2.2.1 The constructor of ClassC at line 27
2.2.2 The method method1C on class ClassC at line 30
The above represents the third iteration of the tool.
For the item 2.2.1 and 2.2.2 above determine the declarations. In so doing, the following is determined. The other item (2.1) is ignored in this iteration, as it does not have any method or constructor invocations in it.
2.2.1 The constructor ClassC starts at line 4 and ends at line 6 in Code Snippet 3
2.2.2 The method method1C of the class ClassC starts at line 9 ad ends at line 11 in Code Snippet 3.
For each of the above method and constructor invocations (2.2.1 & 2.2.2), determine the methods and constructors invoked in them.
2.2.1 There are no methods or constructors invoked within the constructor ClassC
2.2.2 There are no methods or constructors invoked within the method method1C of the class ClassC
This ends the process, since in both of the above items no further methods or constructors are invoked. The Call Tree is derived by putting together the method invocations derived above in the three iterations in the recursive order in which they are invoked. For the above example, the Call Tree for the specified start point would look like the following.
0. ClassA—Method: method1A (The specified start point)
1. ClassB—Constructor: Class B (New instance of ClassB—instClassB1)
2. ClassB—Method: method1B (invoked on instClassB1)
2.1 ClassB—Method: method2B (invoked on instClassB1)
2.2.1 ClassC—Constructor: ClassC (new instance ClassC—instClassC2)
2.2.2 ClassC—Method: method1C (invoked on instClassC2)
3. ClassC—Constructor: ClassC (New instance of ClassC—instClassC1)
4. ClassC—Method: method2C (invoked on instClass1)
New instances of classes are created at steps 1, 2.2.1 and 3. Each of these may be represented using a different icon in the Sequence Diagram. FIG. 2 shows a Sequence Diagram for the above code snippet examples with the instances of classes represented across the top of the figure and message lines connecting the instances. This information and other related information like line numbers, etc. are stored by the tool in a tree data structure.
Thus, as defined herein, a Call Tree is an ordered recursive sequence of all methods in different classes that are invoked given a method in a class as the starting point. The Call Tree or a valid sub-tree is representative of the Sequence Diagram. This concept is used in the Code Tree Analyzer tool of the present invention.
Before describing the details of the flow charts, a general description of the use and operation of the Code Tree Analyzer tool will be provided. The first step in using the Code Tree Analyzer tool is defining a project workspace. At the minimum, a project workspace contains the complete paths of the Java source code files that are to be analyzed to create the design artifacts. In addition to the paths, the project workspace includes a list called "Ignores". Ignores is a list of class names that will be ignored while creating the different design work products. Ignores are used to filter out those classes that the user does not wish to include in the design artifacts generated by the tool.
Design artifacts are the different work products that are created using the tool. The tool creates UML-compatible model files for the Sequence and Class Diagrams and text and rtf files containing the call tree. The tool also stores data on the work products that have been created. As previously described, this data is later used to determine the impacted work products when any of the source code files in the project is modified.
To begin analyzing the Java source files in the project, it is first necessary to select a start point. Again, a start point is a combination of a class name and a method in the class. This is used by the tool to create a Call Tree beginning at the selected start point. Additionally, while analyzing the source files, the tool also determines the relationships between the classes. These relationships are used to generate the Class Diagrams.
The Call Tree that is generated based on the specified start point is used to create a Sequence Diagram that is displayed in the tool. The depth of the Call Tree (and hence the Sequence Diagram) can be controlled by selectively including and excluding Java source code files in the project. If a call is made into a class for which the source code file has not been included in the project, the corresponding path in the Call Tree stops there. The tool, however, also displays those classes that are not in the project but whose methods have been invoked along a Call Tree path. Such classes occur only as leaf nodes in the Call Tree.
The tool includes the feature of providing the ability to update a Sequence Diagram by deleting icons, deleting messages or updating existing messages. The Sequence Diagram can then be saved in UML-compatible format. The tool remembers all the manual updates to the Call Tree that was used to generate the Sequence Diagram. This data is later used to reapply the manual updates to the Call Tree when the generated diagram is impacted due to changes made to any source file included in the project.
The tool also provides features that allow the user to save the Call Tree in either text or rtf format. The text format is a detailed version that also includes the line numbers in the source files where the various methods have been invoked. This may be used to determine the complete call tree for a method during debugging. The rtf format is a summary version where calls made by only the method specified in the start point are included.
The default Class Diagram is generated using the class specified in the start point as the center of the universe. Only relationships of this class with the other classes are displayed. This allows for optionally including other relations using features provided by the tool. Displayed relations can also be selectively hidden. The UML-compatible model files are generated based on the currently displayed diagrams.
The tool stores the time stamps for the Java source files in the project to determine if any source file included in the project has changed. Later, when a project is re-opened, the tool compares the latest time stamps of the source code files with the stored timestamps. A mismatch of time stamps is taken as an updated file.
If the tool finds a source file that has been changed, it is able to search through the work products that were previously generated to find out how many of these are impacted and hence need to be updated. The user is prompted to update these work products. All manual updates that were previously made by the user on the design artifacts can be replayed manually on the newer versions.
The tool also has a built in differencing algorithm that is capable of determining the extent of change between the original design artifacts and the new ones. The differencing algorithm is applied to the Call Trees used to generate the design artifacts. In many cases the design artifacts can be updated without any manual intervention. The tool is capable of applying the manual updates made to the original call tree to the new one.
Additionally, the tool may operate to generate basic code metrics for the analyzed files. They may include, for example, the physical number of lines, the number of shipped source instructions, total number of lines containing comments, code to comment ration, etc. This feature may also be used, for example, to quickly analyze code and verify it against coding guidelines.
The tool first parses the Java source files to determine the Variable Declarations, Method Declarations, Constructor Declarations, Method Invocations and Constructor Invocations. The tool then resolves all the variables to determine their data types. This includes resolving the return types for invoked methods to determine the signature of other methods that use these return values as arguments. The tool also resolves method signatures. Then, the method invocation order is resolved for compound statements. This is a preliminary step to developing the Sequence Diagram. The tool then generates a Call Tree based upon the selected start point. The Call Tree is then used to generate a Sequence Diagram. This is simply done by drawing the method calls as messages in the Sequence Diagrams in the same order in which they appear in the Call Tree.
FIG. 3 shows the basic model for the Code Tree Analyzer tool. The Names of files 31 and Source files 33 of the Java application program to be parsed are parsed by Java File Parser 35 to identify the blocks defining Method Declarations, Variable Declarations, Method Invocations and Constructor Invocations. The symbols (the method names, constructor names and variable names) occurring in each of the identified blocks are stored in a Symbol Table. Call Tree Generator 39 takes the Symbol Table formed by Parser 33 and creates a Call Tree starting at the user specified method and class. An example Call Tree is shown at 41.
The output from the Call Tree Generator is fed to Model Generator 43. Model Generator 43 generates the Class Diagram and Sequence Diagram. The Ignores, i.e., the Names of Classes 45 to be filtered out of these Diagrams are also fed to Model Generator 43 so that the resulting design artifacts generated by the tool is a function of both the specified method and class starting point and the specified class names to be filtered out. An example of a Filtered Tree is shown at 47. Diagram Data 50 represents an intermediate data store that contains graphic data on the Sequence Diagrams and Class Diagrams. This graphic data is used by Viewer & Editor 49 to render these Diagrams. As shown, the Sequence Diagram is displayed by Viewer & Editor 49. The Call Tree, in a tree view, is also displayed in a manner to allow for editing specific values. A displayed example is shown at screen 51.
FIGS. 4A-E show flow charts representing the main process flow of the Code Tree Analyzer tool. The Node 11.0 represents the Start Point for the Main Flow. The Main Flow may be split into the following main steps:
Creation and maintenance of projects
Analysis of the source code files to create the Call Trees and symbol tables
Rendering the Call Trees as a Sequence Diagrams
Using the Symbol tables to create Class Diagrams
Generating design artifacts
Analyzing impacts to previously generated design artifacts and updating them
The first step in starting the process, is get the Project Name, identified as step 11.1. The Project may be an existing project or a new one to be created by the tool. Each project is identified by a unique name and consists of an Inputs File, Data File, Time Stamps File, Ignores File and Project Data File.
The Inputs File stores the complete paths of the source code files that are to be analyzed as part of this project. The Data File stores the unresolved symbol table for the analyzed files. The intent of storing this data is to optimize the time spent on analyzing the source files if the project is re-opened at a later time. During later runs of the tool for the same project, the tool only analyzes those files that have been modified since the previous run of the tool. This helps save time as analyzing files for a large project with many files takes time.
The Times Stamps File stores the timestamps for the source code files. This data is used in later runs of the tool for the same project to determine the source code files that have changed. The Ignores File stores a list of class names that have to be ignored while creating the sequence diagram, class diagram or any other design artifact. This file allows the user to selectively filter out classes that he is not interested in displaying in the diagrams. For example, the user may choose to filter out all the standard Java classes to avoid making the sequence diagrams unmanageable. The Project Data File stores details about the design artifacts created using the tool. This data is used in the later runs of the tool for the same project to determine the impacted work products due to changes made to source code files.
In addition to the above, the tool maintains a Master File that contains the details of all the projects created using the tool. This file stores the project names and the complete paths of the above files for each project. Thus, if a project does not exist in the Master File, a new Project is created, as shown at step 11.3 and in FIG. 5.
At the time of creating a project, the user specifies the source code files to be included therein and the symbols to be ignored. The Inputs File and the Ignores File are created as soon as a new project is created. However, the timestamps file, data file and project data file are created at a later time. The master file is only updated with the complete paths for these files at the time of project creation.
If the Project already exists in the Master File, the Project file names are retrieved from Master File 11.4. The tool at this point gets the full paths of the Inputs File, Data File, Time Stamps File, Ignores File and the Project Data File. Next, it is determined whether a Timestamps file exists for the Project file names.
When a new project is created, none of the associated files for the project would exist even though the paths for these files would have been specified in the Master file at the time of project creation. If a Timestamps file does not exist, one is created, as shown at step 11.7 and in FIG. 6. If a Timestamps file does exist, the tool loads the Timestamps for the source code files into the process, as shown at step 11.8. These are the Timestamps for the source code files that were saved from the previous run of the tool for the same project.
Next, a check is made to determine if a Data file exists, as shown by step 11.10. If a Data file exists, the Symbol Table for the previous run of the tool for the same project from the Data File is loaded into the process. In this run of the tool, only those source code files that have been updated would be re-analyzed. The tool compares the current time stamps of the source code files with those saved from the previous run of the tool (in the time stamps file) to determine the updated files. Storing the symbol table from the previous run of the tool for a project and reloading it at the next run helps save time in reanalyzing all the source code files.
The node 11.13 in the flow chart represents the Data file. This is a binary file which, in the current implementation for Java, uses standard Java object serialization techniques to save the symbol table data structures directly. If a Data files does not exist, one is created, as shown by step 11.11.
The Source Code File Names to be analyzed from the Inputs File are then loaded into the process, as shown by step 11.15 in FIG. 4B. The tool loads the complete paths of the source code files that need to be analyzed as part of the project from the Inputs File for the Project. The Inputs File is created when a new project is defined.
After loading in the Source Code File Names, each source code file name is looped through steps 11.17 to 11.26, as shown in FIG. 3B. In doing this, it is first determined whether a source code file exists for the first source code file name. If not, it is removed from the Timestamps and Data File as shown at step 11.18 and the process goes to the next file name. If the file does exist for the source code file name, a new time stamp is obtained for the source code file and a determination is made at step 11.20 if a loaded timestamp already exists for the file. If not, the Source Code File is read and parsed, as shown by step 11.24 in FIG. 4C. If a loaded timestamp already exists for the file, it is retrieved and compared to the new time stamp, as shown by step 11.22. If the time stamps are different, the Source Code File is read and parsed, as shown by step 11.24 in FIG. 4C. If the time stamps are not different, the file is skipped and the process loops back to the next file.
After reading and parsing the source code files in step 11.24 in FIG. 4C, the Parse Tree and Symbol Table data structures for the source Code File are updated in step 11.26 and the process loops back to step 11.16 in FIG. 4B.
In this regard, it should be understood that the Symbol Table is a collection of data nodes where each node may contain the following details.
Symbol Name—This is the name of the symbol. Could be set to a method, variable or constructor name.
Symbol Type—This is the type of the symbol. Could be set to any one of method declaration, constructor declaration, variable declaration, method invocation or constructor invocation.
Method Signature—This is the resolved signature of the method or constructor. This value is set for all the types but for variable declaration.
Original Method Signature—This is the original unresolved signature of the method or constructor. This value is set for all the types but for variable declaration.
Data Type—The data type of a variable or the variable on which a method is invoked.
Return Type—The data type of the return value for a method.
Block Number—The code block in which the symbol was found.
Block Hierarchy—The hierarchy of blocks (nested blocks) where the last block is the block number in which the symbol was found.
Line Number—The line number in the source code file where the symbol was found.
The parse tree maintains the block hierarchy for the source code files analyzed. It also maintains other attributes of the class in the source code file. For example in the case of Java, this may include the super classes, the interfaces implemented by the class, the package, etc.
After completing the loops, the next steps are to Save/Update the Symbol Table in the Data File and save/Update the Timestamps File, as shown by steps 11.28 and 11.30 in FIG. 4C. The Symbol Table is the Resolved in step 11.32 and the Start Point of the Sequence Diagram is retrieved in step 11.33. The details of the Symbol Table Resolve step are shown in FIG. 8.
After retrieving the Start Point, the Call Tree is generated in step 11.34, the details of which are shown in FIG. 9. Then a determination is made of whether an Ignores File exists and if it does not, the process moves forward to step 11.39 in FIG. 4D wherein a filtered Call Tree as a Sequence Diagram is rendered. In this regard, the Ignores File is a text file that contains a list of class names, one class per line, that needs to be ignored in creating a design artifact.
If an Ignores File does exist, the symbols corresponding to the classes to be ignored are loaded into the process, as shown by step 11.36 in FIG. 4D. After loading the symbols to be ignored into the process, the Call Tree is filtered to remove ignores and the filtered Call Tree as a Sequence Diagram is rendered and displayed, as shown by steps 11.39 and 11.40.
The Filtered Call Tree is allowed to be manually updated in Step 11.41. The user may delete a node from a tree or edit contents of a node. The manually updated filtered Call Tree is used to create all of the design artifacts. The tool records the manual updates and saves them as part of the Project Data. The tool then takes as input, the design artifact to be created. This input may include.
A Sequence Diagram saved in UML-compatible format
A Class Diagram saved in UML-compatible format
The filtered Call Tree saved in RFT format as a sequence of steps
The unfiltered Call Tree save in Text format as a sequence of steps
The tool then loads the saved details for the project artifacts from the previous run of the tool for the Project, if data exists in the Project Data File. This is shown at step 11.43 in FIG. 4D. Node 11.44 represents the Project Data File. This may be a binary file that stores the following.
Complete paths of the design artifact files generated using the tool.
The filtered Call Tree that was used to create each artifact.
The manual updates made by the user to the each filtered call tree.
The classes that are referenced in the artifact.
In step 11.45 of FIG. 4D, the tool checks if the artifact specified by the user exists in the Project Data. If the artifact does not exist in the project data file, it creates the project artifact. If the project artifact exists in the Project Data, the tool compares the current data for the artifact with the previous data loaded from the Project Data file, as shown in step 11.46 in FIG. 4E. The tool then displays the differences, if any between the current version of the artifact and its previous version, as shown by step 11.47 in FIG. 4E. The tool also displays the manual updates, if any, made to the filtered call tree in the previous version of the artifact.
In step 11.49 of FIG. 4E, the tool allows the user to apply the updates made in the previous version of the artifact to the new Call Tree. The user may make additional updates as well. All the updates re-recorded by the tool. The tool also recreates the new artifact and saves it, as shown in step 11.50. If this was an existing artifact it overwrites the file with the new data. The node 11.51 represents the stored Design Artifacts.
In step 11.52, the tool saves the data for the design artifact in the Project Data File 11.53 also identified as 11.44 in FIG. 4D. Existing data for the artifact, if any is overwritten. The user may also specify more design artifacts to be created using the same filtered Call Tree data, as represented by step 11.54. In addition, as shown by step 11.55, the user may specify more start points for the same Symbol Table data generated by parsing the source code files in the project to create new Call Trees and design artifacts. To do this, the process loop back to step 11.33 in FIG. 4C.
FIG. 5 show a process for creating a New Project in the Code Tree Analyzer tool, as shown in step 11.3 in FIG. 4A. A project in the tool is identified by a unique name. The project name, along with the names of the files that hold the data for the project (as described in step 11.1), are saved in Master File 12.3. The name and location of the Master File for the tool is predefined. Any number of projects may be defined in the tool. However, at any one time, only one project may be active. The user may specify the location where the files for a particular project are saved.
In steps 12.1 of FIG. 5, the tool prompts the user for the Project Name. In step 12.2, the tool checks the Master File to determine if the project by that name already exists. If the Project Name exists, the tool prompts the user of such and allows the user to open the existing project. Only if the Project Name does not exist in the Master File may the user proceed to create a new project by that name.
In step 12.4 of FIG. 5, the Project Name along with the names (including the paths) of the associated files for the project are saved in the Master File. In step 12.5, the tool takes as input the complete paths of the source code files that need to be analyzed as part of this project. The node 12.6 in the flow chart represents the Inputs File, as discussed in regard to Node 11.4 in FIG. 4B. In step 12.7, the tool saves the names and paths of the source code files in the Inputs File for the project. The tool then takes as input the names of the classes to be ignored while creating the diagrams and design artifacts, as shown by step 12.8. The node 12.9 in the flow chart represents the Ignores File, as discussed in step 11.37 in FIG. 4D. In step 12.10, the tool saves the classes to be ignored to the Ignores File for the project. This completes the creation of a new project. The other files for the project are created as required during the process of analyzing the source code files and creating the design artifacts.
FIG. 6 shows a process for creating a new Timestamps File in the Code Tree Analyzer tool, as shown in step 11.7 in FIG. 4A. The node 13.0 represents the start point of the process. The Timestamps File 13.3, corresponding to File 11.9 in FIG. 4A, stores the time stamps for the source code files from the last run of the tool for the project. This data is used in the next run of the tool for the same project to determine which source files have been modified. A difference in the current time stamp and the one stored in the Timestamps File for a source code file is assumed to be due to modifications made to the source code file.
In step 13.1 of FIG. 6, the tool retrieves the name and the path of the Timestamps file for the project from the Master File 13.2 corresponding to Master File 11.4, as shown in FIG. 4A. In step 13.4, the tool then creates a new Timestamps file as shown at node 13.3 and which corresponds to File 11.9 in FIG. 4A. This file is empty to begin with. The tool writes the time stamps for the various source code files to this file after the source code files have been analyzed.
FIG. 7 shows a process for creating a new Data Files in the Code Tree Analyzer tool, as referenced by step 11.13 in FIG. 4A. Node 14.0 represents the start point of the flow for the creation of a new Data File. The Data File stores the Symbol Table for the source code files from the last run of the tool for the project. This data is used in the next run of the tool for the same project to minimize the time spent in analyzing files that have not been modified between the runs. For such files the Symbol Table from the previous run is used unchanged.
In step 14.1 of FIG. 7, the tool retrieves the name and the path of the data file for the project from Master File 14.2 corresponding to File 11.4 in FIG. 4A. The tool then creates a new Data File 14.3, as represented by file 11.13 in FIG. 4A. This file is empty to begin with. The tool writes the symbol table for the source code files to this file after the source code files have been analyzed.
FIG. 8 shows a process for resolving the Symbol Table in the Code Tree Analyzer tool, shown as step 11.32 in FIG. 4C. The node 15.0 represents the start point of the process. After the source code files are parsed to extract the method declarations, constructor declarations, variable declarations, method invocations, constructor invocations and code blocks, the Symbol Table is resolved. In this process, the data types for the variables and the return data types of methods are determined. The objective is to determine the names of the classes, the methods invoked on them and the order in which these methods are invoked. Accordingly, the Resolve Symbol Table process replaces those variable names (either explicit or implicit) in the Symbol Table that represent instances of classes with the corresponding class names. In many cases, the tool may not be able to resolve all the invocations as the source code for the class may not have been included as part of the project. Such unresolved method invocations are represented by a special icon called 'unresolved' in the sequence diagram. The user may choose to delete this icon before creating the design artifacts.
In FIG. 8, Step 15.1 of the Resolve Symbol Table process first resolves the method declarations. The return types of the methods and their signatures are determined from the declarations. This is done for the methods and constructors. This is followed by step 15.2 which resolves the method invocations. Typically methods are invoked on variables. This step determines the data type of the variables, such that it is possible to determine the name of the class on which the method is invoked. This is done both for the explicitly declared variables and the implicit ones. For example, the statement "var1.method1( ).method2( )" has two method invocations, one on var1, an explicit variable. The method method2( ) is invoked on the return type of method1( ) and hence is an implicit variable. The tool acts to resolve the classes that correspond to var1 and the implicit variable that represents the return type of method1( ). The tool also keeps track of the constructor invocations in this step.
Next, the method and constructor signatures are resolved as shown by step 15.3 of FIG. 8. This involves determining the data types of each of the parameters that are passed as arguments to the invoked methods and constructors. The order in which the methods are invoked is important from the perspective of a sequence diagram. In step 15.4, the tool resolves the order in which the methods are invoked. This step is particularly important in the case of compound statements that have multiple method invocations in a single statement. Finally, in step 15.5, the symbol table is updated to reflect the resolved method invocations.
In FIG. 9, a process is shown for generating the Call Tree in the Code Tree Analyzer Tool, as represented by step 16.0 in FIG. 4C. The Call Tree is generated based on the resolved Symbol Table. The Call Tree, in turn, forms the basis for the Sequence Diagram. A start point is required to create a call tree. As previously stated, a start point is a combination of a class and a method in the class. Beginning at the start point, the tool recursively determines the methods that are invoked. This results in the creation of a tree structure for the Call Tree.
In step 16.1 of FIG. 9, the tool takes as input a combination of a class and a method in the class that represents the start point of the Call Tree and hence the Sequence Diagram. The tool retrieves the data for the class in the start point from the resolved Symbol Table, as shown in step 16.2. Using the data in the resolved Symbol Table, the tool determines all the methods and constructors that are invoked within the method in the start point. These invocations may either be on the same class or on other classes. This is shown in step 16.3. As shown in step 16.4, the tool loops through each of these invoked methods and constructors in the method of the start point
After the tool completes the required loops, it retrieves the data for the corresponding classes from the symbol table, as shown in step 16.5 of FIG. 9. If the classes are not included as part of the project the methods are not considered, as shown in step 16.6. If the classes are part of the project, the methods that are in turn invoked in each of these methods are determined. This is shown by step 16.7. In step 16.8, the process is repeated until none of the classes on which methods are invoked are part of the project. The resultant tree that is generated out of the above recursive steps is the Call Tree for the specified starting point. The tool keeps track of the variable names of an instance of classes as it is passed across the different methods in the call tree. The tool keeps this tree in memory and uses it or a filtered version (generated by removing the classes to be ignored) for generating the Sequence Diagram, which will be described with reference to FIG. 10.
With reference to FIG. 10, there is shown the process for rendering a Sequence Diagram. The node 17.0 represents the start point of the process that creates the Sequence Diagram from the filtered Call Tree. The sequence diagram is drawn by traversing the filtered Call Tree in order as shown in step 17.1. For every method invocation in the filtered Call Tree, the process retrieves the invoker and the invoked instances, as shown in step 17.2. Then, for each unique instance of an invoked class, the tool adds an icon to the Sequence Diagram, as shown in step 17.3.
In step 17.4 of FIG. 10, a check is made to see if the invoker and the invoked instances are the same. If the instances are the same, then a check is made for a recursive call. If the call is recursive, the tool adds a labeled self-connector. If the call is not recursive, the tool adds a simple self-connector. This is shown at step 17.5. If the invoker and the invoked instances are not identical then add a connector from the invoker instance to the invoked instance, as shown at step 17.6. Finally, if a self-invocation has terminated, add a return connector. The above steps are repeated till the entire call tree is traversed. As shown, the process returns to step 11.40 in FIG. 4D.
With reference to FIG. 11, there is shown a process for rendering a class diagram from the Code Tree Analyzer tool. The node 18.0 represents the start point of the process that creates the class diagram from the resolved symbol table for the class. The tool is capable to displaying the relationships between a selected class and other classes. The user has to select a class, which is used as the pivot to generate the class diagram. All relationships in the resulting class diagram are displayed between the selected class and other classes that are related to it. Interrelationships between the other classes are not displayed unless the user wishes to explicitly include them. FIG. 13 shows a screen shot of a typical Class Diagram.
To begin the process, the tool retrieves the Symbol Table for the specified class, as shown in step 18.1 of FIG. 11. Then, the tool looks through the Symbol Table for the class to get the member variables in the class, as shown in step 18.3. In step 18.4, the tool looks through the Symbol Table for the classes on which methods or constrictors are invoked. Then, the tool retrieves the super class and the interfaces implemented by the class, if any, as shown in step 18.5. In step 18.6, the specified class is added as the central icon in the class diagram and in step 18.7, the tool adds icons for the classes that were identified in the above steps. FIG. 13 shows a redrawn screen shot of an example of the central icon and related icons.
The tool defines relationships between the classes based on the following rules.
If a class has a member variable in the specified class the relationship is considered to be association.
If a method or a constructor is invoked in the specified class the relationship is considered to be dependency.
The relationship between the specified classes and the interfaces implemented by it is that of realization.
The relationship between the specified classes and its super class is that of generalization.
Also, association takes precedence over dependency. Step 18.8 in FIG. 11 uses these rules to draw the relationships between classes. The process ends at node 18.9. The data generated in the above steps is used to generate design artifacts that contain class diagrams.
FIG. 12 shows a redrawn screen shot of an example of a typical Sequence Diagram. The left panel shows the corresponding Call Tree. A Cross indicates a leaf node. A leaf node represents classes that are not in the project but whose methods have been invoked along a Call Tree path. Similarly, the left panel of FIG. 13 shows the corresponding Call Tree. The purpose of the screen shots, as redrawn in FIGS. 12 and 13, is to demonstrate how the tool may be employed to display the Sequence Diagram and Class Diagram to the user in an interactive mode.
Although description of the process employed by the Code Tree Analyzer tool is based upon the start point being a Class, the tool can, with minimal change, also readily be employed to create Sequence Diagrams with Objects as entities of the start point.
It will be understood from the foregoing description that various modifications and changes may be made in the preferred embodiment of the present invention without departing from its true spirit. It is intended that this description is for purposes of illustration only and should not be construed in a limiting sense. The scope of this invention should be limited only by the language of the following claims.
1. A computer-readable storage device, tangibly embodying a program of instructions executable by a machine to perform method steps for analyzing static source code of a computer program at static time, said method steps comprising:
selecting the static source code of the computer program to be analyzed;
selecting a class and method in the class based upon a selected class name from said selected static source code to be analyzed;
generating a call tree as an ordered recursive sequence of all method calls in different classes or their instances that are invoked by said selected method in said selected class;
generating a sequence diagram using said call tree by presenting the method calls as messages in the same order in which they appear in the call tree; and
storing said sequence diagram, wherein the stored sequence diagram is used to analyze the effect of updates and changes made to the static source code of said computer program.
2. The computer-readable storage device as set forth in claim 1 including the step of storing time stamps corresponding to the time of said step of selecting the static source code of the computer program to be analyzed.
3. The computer-readable storage device as set forth in claim 1 including:
updating said call tree to form new design artifacts;
storing said new design artifacts; and
comparing the call tree used to form said new design artifacts with the call tree used to form any previous design artifacts to determine any differences.
4. The computer-readable storage device as set forth in claim 3 including the step of updating the call tree used to form said new design artifacts with any said differences.
5. The computer-readable storage device as set forth in claim 1 including the steps of generating a plurality of different call trees and corresponding sequence diagrams by selecting different static source code of the computer program to be analyzed and storing the call trees and sequence diagram as work product files.
6. The computer-readable storage device as set forth in claim 5 including the steps of storing time stamps corresponding to the time of selecting said different static source code of the computer program to be analyzed.
7. The computer-readable storage device as set forth in claim 6 including the steps of:
comparing the latest time stamps of the selected static source code with the stored time stamps to determine the static source code that has a mismatch of time indicating that such static source code has changed; and
searching through said work product files to determine which files were impacted by the static source code that has changed.
8. The computer-readable storage device as set forth in claim 7 including the further step of updating the impacted work product files.
9. The computer-readable storage device as set forth in claim 1 wherein said step of generating a call tree includes:
parsing said static source code files to determine method declarations, constructor declarations, variable declarations, method invocations and constructor invocations;
resolving all method and constructor declarations to determine return type of methods and their signatures;
resolving all method invocations having compound statements to determine the data type of both the variables on which methods are invoked and the implicit methods invoked on said methods;
determining the classes corresponding to said variables and said implicit methods; and resolving the order in which said methods are invoked.
10. A computer-readable storage device, tangibly embodying a program of instructions executable by a machine to perform method steps for analyzing static source code of a computer program at static time, said method steps comprising:
accessing the static source code of the computer program to be analyzed;
accessing a class and method in the class based upon a selected class name from said static source code to be analyzed;
generating a call tree as an ordered recursive sequence of all method calls in different classes or their instances that are invoked by said accessed method in said accessed class and creating a stored call tree file of said call tree;
generating a sequence diagram using said call tree file by presenting the method calls as messages in the same order in which they appear in the call tree; and
storing said sequence diagram, wherein said stored call tree and stored sequence diagram are used to analyze the effect of updates and changes made to the static source code of the computer program.
11. The computer-readable storage device as set forth in claim 10 including the step of storing time stamps corresponding to the time of said steps of accessing the static source code of the computer program to be analyzed.
12. The computer-readable storage device as set forth in claim 10 including:
storing said new design artifacts;
comparing the call tree used to form said new design artifacts with the call tree used to form any previous design artifacts to determine any differences; and
updating the call tree used to form said new design artifacts with any said differences.
13. The computer-readable storage device as set forth in claim 10 including the steps of generating a plurality of different call trees and corresponding sequence diagrams by accessing different static source code to be analyzed and storing said call trees and sequence diagrams as work product files.
14. The computer-readable storage device as set forth in claim 13 including the steps of storing time stamps corresponding to the time of accessing different static source code of the computer program to be analyzed.
15. The computer-readable storage device as set forth in claim 14 including the steps of:
comparing the latest time stamps of the accessed static source code with the stored time stamps to determine the static source code that has a mismatch of time indicating that such static source code has changed; and
16. The computer-readable storage device as set forth in claim 15 including the further step of updating the impacted work product files.
17. The computer-readable storage device as set forth in claim 10 wherein said step of generating a call tree includes:
parsing said static source code to determine method declarations, constructor declarations, variable declarations, method invocations and constructor invocations;
18. The computer-readable storage device of claim 10 including the step of displaying said sequence diagram on a display device along with said call tree in a tree view to allow editing.
19. A computer readable storage device, tangibly embodying a program of instructions executable by a machine to perform method steps for analyzing static source code of a computer program at static time, said method steps comprising:
accessing the static source code of a computer program to be analyzed;
accessing a class and method in the class based upon a selected class name from said source code;
parsing the accessed static source code of said class and method in the class to determine variable declarations, method declarations, constructor declarations, method invocations and constructor invocations;
resolving all variables to determine their data type, including resolving the return types for invoked methods to determine the signature of other methods that use these return values as arguments;
resolving method signatures and the method invocation order;
generating a call tree as an ordered recursive sequence of all method calls in different classes or their instances that are invoked by said accessed method in said accessed class;
generating a sequence diagram using said call tree by forming said method calls as messages in the sequence diagram in the same order in which they appear in said call tree; and
US12/105,658 2004-09-09 2008-04-18 Generating sequence diagrams using call trees Active 2027-02-10 US8146055B2 (en)
US10/937,083 US7506320B2 (en) 2004-09-09 2004-09-09 Generating sequence diagrams using call trees
US10/937,083 Continuation US7506320B2 (en) 2004-09-09 2004-09-09 Generating sequence diagrams using call trees
US10/937,083 Expired - Fee Related US7506320B2 (en) 2004-09-09 2004-09-09 Generating sequence diagrams using call trees
US12/100,564 Active 2027-02-20 US8141073B2 (en) 2004-09-09 2008-04-10 Generating sequence diagrams using call trees
US10157057B2 (en) 2016-08-01 2018-12-18 Syntel, Inc. Method and apparatus of segment flow trace analysis
US7073168B2 (en) * 2001-12-06 2006-07-04 Microsoft Corporation Customizing binary content files
US7266726B1 (en) 2003-11-24 2007-09-04 Time Warner Cable Inc. Methods and apparatus for event logging in an information network
US8302111B2 (en) 2003-11-24 2012-10-30 Time Warner Cable Inc. Methods and apparatus for hardware registration in a network device
US9213538B1 (en) 2004-02-06 2015-12-15 Time Warner Cable Enterprises Llc Methods and apparatus for display element management in an information network
US8078669B2 (en) 2004-02-18 2011-12-13 Time Warner Cable Inc. Media extension apparatus and methods for use in an information network
US20060206879A1 (en) * 2005-03-10 2006-09-14 Harold Batteram Java program method invocation display
US7770148B2 (en) * 2005-05-25 2010-08-03 Microsoft Corporation Methods and apparatus enabling diagram customization retention
US8561036B1 (en) * 2006-02-23 2013-10-15 Google Inc. Software test case management
US8307337B2 (en) 2006-12-01 2012-11-06 Murex S.A.S. Parallelization and instrumentation in a producer graph oriented programming framework
US8332827B2 (en) 2006-12-01 2012-12-11 Murex S.A.S. Produce graph oriented programming framework with scenario support
US8191052B2 (en) 2006-12-01 2012-05-29 Murex S.A.S. Producer graph oriented programming and execution
US7865872B2 (en) * 2006-12-01 2011-01-04 Murex S.A.S. Producer graph oriented programming framework with undo, redo, and abort execution support
US8370818B2 (en) * 2006-12-02 2013-02-05 Time Warner Cable Inc. Methods and apparatus for analyzing software interface usage
US8418149B2 (en) * 2006-12-28 2013-04-09 International Business Machines Corporation Differential comparison system and method
EP2026211A1 (en) * 2007-07-31 2009-02-18 Sap Ag Method for automatically creating a behaviour pattern of a computer program for model-based testing techniques
US20090063998A1 (en) * 2007-09-05 2009-03-05 Jinchao Huang Method, system, and program product for collaborative diagram editing
US20090112667A1 (en) * 2007-10-31 2009-04-30 Ken Blackwell Automated Business Process Model Discovery
US8245212B2 (en) * 2008-02-22 2012-08-14 Microsoft Corporation Building call tree branches and utilizing break points
US20090276757A1 (en) * 2008-04-30 2009-11-05 Fraunhofer Usa, Inc. Systems and methods for inference and management of software code architectures
US8769675B2 (en) * 2008-05-13 2014-07-01 Apple Inc. Clock roll forward detection
US8347273B2 (en) * 2008-10-09 2013-01-01 International Business Machines Corporation Tracing a calltree of a specified root method
US8296723B2 (en) * 2008-12-11 2012-10-23 International Business Machines Corporation Configurable unified modeling language building blocks
US20100251211A1 (en) * 2009-03-26 2010-09-30 Microsoft Corporation Generating and using code-based diagrams
DE102009024861A1 (en) * 2009-06-09 2010-12-16 Hoffmann, Dieter, Dr. Method for preparing programming language independent representation of vending machine control, involves importing control stage by identification of individual logical content of each control stage and arguments
DE102010001765A1 (en) * 2010-02-10 2011-08-11 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V., 80686 Method for testing compliance of implementation of software architecture, involves selectively suppressing new determination of information during determination of source code and structure models and during comparison of structure models
US8522217B2 (en) * 2010-04-20 2013-08-27 Microsoft Corporation Visualization of runtime analysis across dynamic boundaries
US20110271253A1 (en) * 2010-04-28 2011-11-03 International Business Machines Corporation Enhancing functional tests coverage using traceability and static analysis
US8918765B2 (en) * 2010-06-18 2014-12-23 Libera, Inc. Auto-documenting based on real-time analysis of code execution
US8671398B2 (en) * 2011-05-03 2014-03-11 Microsoft Corporation Working set profiler
US9069788B2 (en) * 2011-07-01 2015-06-30 Salesforce.Com, Inc. Truncating data associated with objects in a multi-tenant database
US9003379B2 (en) * 2011-12-12 2015-04-07 Zynga Inc. Methods and systems for generating test information from a source code
JP5967603B2 (en) * 2011-12-21 2016-08-10 インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation Method for searching for change contents in source code from plural change history data, and computer and computer program thereof
CN103186406B (en) * 2011-12-30 2016-08-17 国际商业机器公司 Method and apparatus for control flow analysis
US20130191809A1 (en) * 2012-01-25 2013-07-25 Microsoft Corporation Graphical representation of an order of operations
US9158504B2 (en) * 2012-10-12 2015-10-13 Baker Hughes Incorporated Method and system to automatically generate use case sequence diagrams and class diagrams
US8863099B2 (en) 2012-11-05 2014-10-14 International Business Machines Corporation Compilation and placement of instructions in a memory system
US8914778B2 (en) * 2012-11-05 2014-12-16 International Business Machines Corporation Data placement for execution of an executable
US9389986B2 (en) * 2013-05-06 2016-07-12 Microsoft Technology Licensing, Llc Identifying impacted tests from statically collected data
US9183120B1 (en) * 2013-06-04 2015-11-10 The Mathworks, Inc. Functional dependency analysis
US9146842B2 (en) * 2013-08-15 2015-09-29 Yahoo! Inc. Testing computer-implementable instructions
CN103984578B (en) * 2014-05-29 2017-08-25 中国银行股份有限公司 The update method and device of a kind of cobol program version
US10452635B2 (en) * 2016-03-23 2019-10-22 Microsoft Technology Licensing, Llc Synchronizing files on different computing devices using file anchors
JPH06324967A (en) 1993-05-14 1994-11-25 Hitachi Ltd Message sequence diagram generating method
US5452449A (en) * 1991-07-03 1995-09-19 Itt Corporation Interactive multi-module source code analyzer that matches and expands call and entry statement parameters
EP0801346A1 (en) 1996-04-10 1997-10-15 Sharp Kabushiki Kaisha Retargetable device for generating assembly-language programs from extended tree structure diagrams
US5752245A (en) 1994-12-09 1998-05-12 Object Technology Licensing Corporation Object-oriented system for configuration history management with a project workspace and project history database for draft identification
US5963739A (en) 1996-04-26 1999-10-05 Peter V. Homeier Method for verifying the total correctness of a program with mutually recursive procedures
US6002872A (en) 1998-03-31 1999-12-14 International Machines Corporation Method and apparatus for structured profiling of data processing systems and applications
US6029004A (en) 1997-03-17 2000-02-22 International Business Machines Corporation Method and apparatus for modular reordering of portions of a computer program based on profile data
US6219826B1 (en) 1996-08-01 2001-04-17 International Business Machines Corporation Visualizing execution patterns in object-oriented programs
US6330527B1 (en) 1998-08-11 2001-12-11 Electronics And Telecommunications Research Institute Apparatus and method for modeling frameworks via use of object-oriented analysis information
US6457170B1 (en) 1999-08-13 2002-09-24 Intrinsity, Inc. Software system build method and apparatus that supports multiple users in a software development environment
US20030066055A1 (en) 2001-04-26 2003-04-03 Spivey John Michael Profiling computer programs
US6557011B1 (en) 2000-10-31 2003-04-29 International Business Machines Corporation Methods for analyzing dynamic program behavior using user-defined classifications of an execution trace
US20030088854A1 (en) 1999-12-23 2003-05-08 Shlomo Wygodny System and method for conditional tracing of computer programs
US20030088860A1 (en) * 2001-11-02 2003-05-08 Fu-Hwa Wang Compiler annotation for binary translation tools
US6594783B1 (en) 1999-08-27 2003-07-15 Hewlett-Packard Development Company, L.P. Code verification by tree reconstruction
US20030212984A1 (en) 2000-12-08 2003-11-13 Fujitsu Limited Sequence analysis method and apparatus
US6651243B1 (en) 1997-12-12 2003-11-18 International Business Machines Corporation Method and system for periodic trace sampling for real-time generation of segments of call stack trees
US20040031015A1 (en) 2001-05-24 2004-02-12 Conexant Systems, Inc. System and method for manipulation of software
US20040264367A1 (en) 2003-06-26 2004-12-30 Microsoft Corporation Data flow chasing
US20050010899A1 (en) 2003-07-11 2005-01-13 Kung David C. Recovery and representation of object interaction in an object oriented program
US6851107B1 (en) 1999-10-05 2005-02-01 Borland Software Corporation Software development tool with instant updating and simultaneous view of graphical and a textual display of source code
US20050204344A1 (en) * 2004-03-12 2005-09-15 Hideaki Shinomi Program analysis device, analysis method and program of same
US20050273757A1 (en) * 2004-06-07 2005-12-08 Anderson Craig D Methods, systems, and computer program products for summarizing operational behavior of a computer program
US20050278183A1 (en) 2004-06-10 2005-12-15 Glenn Ammons Finding and removing performance bottlenecks in large systems
US6996516B1 (en) * 1998-02-05 2006-02-07 Ns Solutions Corporation Apparatus for analyzing software and method of the same
US7167870B2 (en) 2002-05-08 2007-01-23 Sun Microsystems, Inc. Software development test case maintenance
JP2007287045A (en) * 2006-04-19 2007-11-01 Sharp Corp Packaging progress measuring apparatus, packaging progress measuring program and recording medium recorded with packaging progress measuring program
US645717A (en) * 1898-09-20 1900-03-20 Patent Case Company Abrading-machine.
CA2175711A1 (en) * 1996-05-01 1997-11-02 Lee Richard Nackman Incremental compilation of c++ programs
US6901579B1 (en) * 1996-11-07 2005-05-31 Fujitsu Limited Generation of source code from classes and maintaining the comment that indicates the role of the class in the generated source code
EP1290552A1 (en) * 2000-04-21 2003-03-12 Togethersoft Corporation Methods and systems for identifying dependencies between object-oriented elements
US20040010780A1 (en) * 2002-07-11 2004-01-15 Nortel Networks Limited Method and apparatus for approximate generation of source code cross-reference information
US7346897B2 (en) * 2002-11-20 2008-03-18 Purenative Software Corporation System for translating programming languages
US7392514B2 (en) * 2003-06-26 2008-06-24 Microsoft Corporation Data flow chasing
US7426716B2 (en) * 2003-07-11 2008-09-16 Board Of Regents, The University Of Texas System Recovery and representation of object interaction in an object oriented program
Jacobs, et al. "Interactive Visual Debugging with UML", ACM 2003, pp. 115-122.
Kern et al., "Effective Sequence Diagram Generation", 2003, Borland. *
Liao et al., "A Reverse Engineering Portal Web Site", Nov. 2002. *
Musial, et al. "UML Assisted Visual Debugging for Distributed Systems", 2003.
Notice of Allowance (Mail Date Nov. 9, 2011) for U.S. Appl. No. 12/100,564, filed Apr. 10, 2008.
Notice of Allowance (Mail Date Oct. 17, 2011) for U.S. Appl. No. 12/349,755, filed Jan. 7, 2009.
Notice of Allowance (Mail Date Oct. 31, 2008) for U.S. Appl. No. 10/937,083, filed Sep. 9, 2004.
Reverse Engineering of the Interaction Diagram from C++ Code by Paolo Tonella, et al. Publ. In IEEE Proc. of the Internat. Conf. on Software Maint. (ICSM'03) Sep. 22-26, 2003.
Richner, et al. "Using Dynamic Information for the Iterative Recovery of Collaborations and Roles", Proceedings of the International Conf. on Software Maintenance, 2002, IEEE.
Rountev et al., "Control Flow Analysis for Reverse Engineering of Sequence Diagrams", 2004. *
Surendranath Ramasubbu, "Reverse Software Engineering Large Object Oriented Software System using the UML diagrams", 2000. *
Kersten et al. 2006 Using task context to improve programmer productivity
Visser 2007 WebDSL: A case study in domain-specific language engineering
Czarnecki et al. 2006 Feature-based survey of model transformation approaches
Ekman et al. 2007 The jastadd extensible java compiler
Ierusalimschy et al. 1996 Lua—an extensible extension language
US6807548B1 (en) 2004-10-19 System and methodology providing automated selection adjustment for refactoring
US8494832B2 (en) 2013-07-23 Method and apparatus for software simulation
Kolovos et al. 2006 The epsilon object language (EOL)
US6269475B1 (en) 2001-07-31 Interface for object oriented programming language
Engels et al. 1992 Building integrated software development environments. Part I: tool specification
US9311057B2 (en) 2016-04-12 Action languages for unified modeling language model
US6769095B1 (en) 2004-07-27 Hierarchically structured control information editor
US6408430B2 (en) 2002-06-18 Interactive software testing system and method
Dig et al. 2005 The role of refactorings in API evolution
Kästner et al. 2012 Type checking annotation-based product lines
Gansner et al. 2000 An open graph visualization system and its applications to software engineering
CA2144874C (en) 2000-07-18 Incremental build system
JP5204070B2 (en) 2013-06-05 Method for generating a tool for merging customizations made to a first version of a software product when migrating to a second version of the software product, a computer usable medium and a data processing system
US5325533A (en) 1994-06-28 Engineering system for modeling computer programs
US6067641A (en) 2000-05-23 Demand-based generation of symbolic information
US7694272B2 (en) 2010-04-06 Method, a language and a system for the definition and implementation of software solutions by using a visualizable computer executable modeling language
US6226787B1 (en) 2001-05-01 Visualization method and system for dynamically displaying operations of a program
US7188332B2 (en) 2007-03-06 Methods and systems for relating a data definition file and a data model for distributed computing
US7614040B2 (en) 2009-11-03 System and method for efficiently analyzing and building interdependent resources in a software project
US20060064677A1 (en) 2006-03-23 Debugger and method for debugging computer programs across multiple programming languages


I have been the victim of a hostile work environment, sexual harassment, discrimination, and retaliation for about the last two months. My supervisor is the one who is harassing and discriminating against me. I couldn't take any more humiliation in front of my teammates. So, due to the emotional distress, I gave my two weeks notice. Since I've quit, do I still have a case?
This is an interesting question for a lot of reasons, and the short answer is that, yes, the employee still has a case, assuming that they had a case in the first place. Let's talk about the impact that the employee's decision to quit has on that case.
Does the Employee Have Any Sexual Harassment Claims?
I'll start by saying that we don't know if the employee has any employment law claims. We're not going to answer that question, either. We are going to assume that whatever the employee has been subject to legally qualifies as (1) hostile work environment sexual harassment, (2) discrimination, and (3) retaliation for some form of protected activity like a complaint about sexual harassment. That allows us to focus on the real question: whether those three employment law claims still exist after the employee quits her job. They do.
That's because when the employee quit, history didn't change. What I mean is that she had already suffered through illegal discrimination, harassment, and retaliation. So she would still be entitled to any damages that she was entitled to as a result of those employment law violations before she quit. Quitting doesn't change that.
The Damages for those Three Claims Might be Minimal.
There is, however, a catch: those three claims might not be worth a lot in terms of monetary damages. You see, the employee was earning her wages during the two months that she suffered at work. That means that she doesn't have any lost wages to recover for that timeperiod. It's likely that all she would be able to recover, for those three violations, are emotional distress damages. And unless the employee suffered a diagnosable psychological condition, two months of general emotional distress damages are unlikely to be large.
But What About Lost Wages Stemming From The Resignation?
But, you might ask, what about the employee's lost wages now? Isn't the employee losing pay now that she quit? Of course she is. And I suspect that the employee is primarily interested in whether the employer bears any liability for that. In this case, the answer is a bit more complex.
Employers can be held liable for the lost wages of employees when those employees quit, under a theory called constructive discharge. Constructive discharge is a legal theory that essentially treats an employee's decision to quit as a termination, for the purposes of assessing liability and calculating damages.
They made a decision to resign that was reasonable given the totality of circumstances.
See Penn. St. Police v. Suders, 542 U.S. 129, 147 (2004). In addition, in cases like this employee's where the decision to resign doesn't appear to follow some form of official company action like a demotion, reassignment, or decrease in pay, the employer has access to a legal defense stemming from two Supreme Court Cases referred to as the Faragher/Ellerth defense. The employer can thus get off the hook if they show that they have an effective anti-harassment/anti-discrimination policy in place and that the employee failed to avail herself of it.
So what does all of this mean? It means that employees like the one who wrote in do have access to relief through the courts, but that relief is harder to achieve than in "simple" sexual harassment cases.
How hard? Well, according to Georgia Southern University Professors Stephanie Sipe and Michael Wiggins, in their 2011 article, "The Legal Fiction of Constructive Discharge as Decided by Federal Courts in Employment Discrimination Claims," in the Academy of Legal Studies in Business Journal of Employment and Labor Law, the constructive discharge doctrine has "been eviscerated in most cases of workplace harassment brought by employees." As Professors Sipe and Wiggins point out, Federal Courts appear to be all-too-eager to use a procedural tool, the motion for summary judgment, to toss out constructive discharge claims before they ever get to a jury. As a result, the already-monumental task of winning a sexual harassment case is made even more difficult when the employee resigns before termination.
First, Before Deciding Whether to Quit, Speak with an Employment Attorney who Focuses on Representing Employees.
This firm, J. Madison PLC, as well as many of the attorneys who are members of organizations like the National Employment Lawyers Association or the Metropolitan Washington Employment Lawyers Association, focuses on representing employees and is familiar with the issues raised in sexual harassment cases. A competent and experienced employment attorney can likely help end the sexual harassment and prevent the need to resign. And if they can't do that they can help protect the viability of any necessary legal action and resulting monetary damages.
Second, Follow Your Employer's Written Steps for Reporting Sexual Harassment and Discrimination.
Preferably, you want to make this complaint with the help of counsel, but certainly in writing. If possible, you want to submit a version or confirmation of the complaint through an electronic system that will create a record or through email or certified mail with a return receipt. When you make the complaint, use the words "sexual harassment" and "discrimination" so that it's clear you are seeking the company's help to end illegal behavior. This will go a long way toward placing the burden of action on the employer to stop and prevent further harassment or discrimination. Even if the company later decides that there was no harassment or discrimination, the employee is in a better position once they've complied with the anti-discrimination policy.
Finally, an Employee Facing Sexual Harassment Should Consider Looking for a New Job.
Sexual harassment law, like most civil law, is only designed to make employees whole for any harassment they suffer. That means that winning a lawsuit can be a rather hollow end to what is often a years-long expensive legal struggle. Employees who win lawsuits generally only receive the amount of damages they suffered, their costs and reasonable attorneys fees, and no more (with some exceptions). So an employee who wins a sexual harassment lawsuit may feel like all they've been able to do was get back to zero. Adding insult to injury is the reality that most cases settle, and the incentive for the employer to settle is the employee's willingness to take less than 100% of the damages they might win at trial. Therefore, sometimes the best course of action is to find an employer and colleagues who respect you and won't treat you illegally, even as you attempt to achieve compensation for the harassment you've already suffered. This may reduce the size of any potential settlement or damages award in your legal case, but it will probably result in a better career and more happiness.
And if an employee finds themselves in the situation our questioner has (they've already quit), they should not despair. As I pointed out above, the constructive discharge doesn't remove access to relief for employment law violations that occurred prior to the resignation. And however flawed the courts' application of the doctrine, it does make recovery of post-resignation lost wages possible. At the same time, however, it just might make the case harder to win or settle, thus the rational employee will accept a lower settlement offer in the average constructive discharge case than they would in a similar termination case. But there may very well still be value in a constructive discharge case, so a constructively-discharged employee should speak with an employment law firm like J. Madison PLC to quickly move to protect their rights.


text:
Brodeur's Save Percentage
The main evidence that Martin Brodeur is a team creation is his save percentage record. Save percentage measures how good a goalie is at stopping the puck. Studies have shown that save percentage is not affected by how many or how few shots a goalie faces. The only hidden factor affecting save percentage is the quality of shots faced. As I have demonstrated repeatedly, shot quality measures have all overwhelming shown that Brodeur is hardly disadvantaged in that area.
Let's look at his record in terms of league ranking. I only included goalies who played in at least half the games in that season, i.e. starting goalies only.
Brodeur's Save Percentage Ranks:
1994: 4th
1995: 17th
1997: 2nd
Not only has he never led, he has only been in the top 5 among starting goalies four times, and in the top 10 7 times in 13 full seasons. Nearly half the time, Brodeur has finished outside of the top 10 in save percentage, including 4 times when he ranked 16th or lower.
Looking at those numbers, you wouldn't immediately guess that he has led the league in wins in 8 of the last 9 seasons. How did that happen? Do the wins overrule save percentage and shown it to be flawed? Of course not. Brodeur plays more games than anyone else, so he gets more opportunities to win. His team has also played a consistently successful style that contributes greatly to his performance.
Brodeur is a solid goalie, and at times, such as through much of this year, he has been great. But his career as a whole is clearly not elite. These stats also seem to point to the conclusion that 2007 was a bit of a fluke. It will be interesting to see whether he can repeat this year's success or whether he will revert to the 10th-15th ranked performance he delivered for the 6 seasons prior.
Posted by The Contrarian Goaltender at 12:51 p.m.
I am not on the Brodeur bandwagon by any means, but he is far better than average, as far as NHL goaltenders go. You hit the nail on the head: He has played more games than anyone else. The difference between a stellar and below average goal tender in the NHL is one goal a game. that equates to making roughly 4-5% more saves.
Think about that, the difference between a great NHLer and an average one is (about) 1 successful play a game. Now over the course of a season the fatigue that comes with playing 70+ games can certainly rob someone of some of their focus and explosiveness. To maintain a save percentage that was about league average in your worst year, over a nearly 20 year career is impressive. Think of the three hardest saves Martin Brodeur makes in a week of play, if he doesn't make them, he's average. But he does, and he isn't.
There are also a few other holes in the theory:
1. Stats lie. Look back at the 2005 Superbowl. The Seahawks statistically stomped the crap out of the Steelers. The Steelers won.
2. Hockey IS a team sport and what is conveniently left out of any Devils argument is the amount of goals they scored. They were second only to Detroit in the 90's and up until the lockout 2nd or 3rd. So, you can't come out and talk about defence all of the time, when the Devils, for most of Marty's career, controlled play in the offensive end as well.
3. In most team sports, this logic can be applied. How about Joe Montana gets drafted by the Tampa Bay Bucs? Emmitt Smith a lifelong Saint?
4. Also, the Brodeur stat most forgotten: His GAA lowers the MORE shots he faces.(Which explains the post lockout/Stevens/Neidermayer decrease in GAA) So one could argue that the Devils team defense HURT his chances for a better GAA, not helped.
5. Finally, and also conveniently left out...rule changes. Not one of your "underrateds" has ever had a rule changed to specifically stop them. The trapezoid might just as well be called the Brodeur zone. For a league interested in picking up scoring, they sure went out of their way to stop Marty from slinging that puck out of his own end to a rushing forward. Imagine how a team would have to plan line changes around Brodeur if he could sling it to an open forward across the redline on a sloppy change.
As far as your underrateds...the selection of Cujo is nothing short of laughable. The Toronto teams in front of him were Stanley Cup contenders, he just wasn't good enough to finish for them. In fact, if memory serves, Joseph was so bad leading up to the 2002 Olympics, he was displaced by Marty and won the gold. For your "team" theory to hold true, Joseph would have shined in the 2002 games rather than to lose his spot to a back-up. Why is Hasek on the list? His resume says anything other than underrated. On some of the younger guys the jury is still out. Arturs Irbe??? One hit wonder.
March 21, 2009 at 5:24 p.m.
Cy Young must have been a fraud too.
May 12, 2009 at 11:26 p.m.
Taking to the ice 60, 65, 70, 75 times a season and having success much of the time as a goaltender is impressive in and of itself. I think that the save percentage stat is not the best form of statistical analysis for a goalie who plays a heck of a lot more games than nearly all other goalies in the league.
Think about it. Goalies who play maybe 50-55 times a season have more time to prepare, rest, watch film, do research on shooters, and perhaps most importantly (I would think), mentally shut it down here and there. Marty does not have that luxury.
I think some of your other arguments are far more convincing than this one. I would be more interested to read an analysis of the stats of the goalies who played a similar number of minutes as Brodeur each season, and then also see how that reflected in their playoff stats... assuming they appeared in the postseason. If I have time, I might just do it myself.
February 23, 2012 at 11:52 a.m.
Custom Assignment Help online produces different assignments, including Custom Assignment Writing Service, to help students deal with the Legit Essay Writing Servicechallenges they face every day.
Hasek vs. Brodeur in the Playoffs
Patrick Roy and the Luck of the Draw
Why Luongo Never Made The Playoffs in Florida
Missed Shots
The Importance of Asking "What If?"
Playoffs 2nd Round: The Better Goalies All Lose
If Brodeur Was a Forward
Ryan Miller and the Grant Fuhr Defence
Cujo the Choker
The 10 Types of Overrated
Why You Can't Say Anything Bad about Brodeur
Brodeur's Playoffs 2007 - Analysis
Somebody Agrees With Me
Brodeur's Playoffs
Simpson's Paradox
The Disciplined Devils

redpajama_set_name: RedPajamaCommonCrawl


text:
Vol. 11, Issue 29 - Sunday, January 29, 2006
ILLUSTRATION BY KIP AOKI / KAOKI@STARBULLETIN.COM
Case's challenge of Akaka rocks the Democratic Party boat
By Richard Borreca
rborreca@starbulletin.com
Seniority and experience versus the ability to do the job not just today but for the next two decades is the first big issue in the Democratic Primary race between Sen. Dan Akaka and U.S. Rep. Ed Case.
By raising the issue, Case says he is running against Akaka and Hawaii's political culture of not making waves. The culture is stifling the next generation, Case claims.
Since declaring to run against Akaka -- a 30-year congressional veteran, Case reports people telling him, "This is not the way it is done."
PBS INTERVIEWS
U.S. Sen. Dan Akaka and U.S. Rep. Ed Case will appear in separate half-hour interviews in a PBS Island Insights special tomorrow at 7:30 p.m.
The interviews will be rebroadcast at 3: 30 p.m. next Sunday on PBS (Oceanic Channel 10, KHET Channel 10, KMEB Channel 11).
Island Insights is co-sponsored by the Honolulu Star-Bulletin.
Dan Boylan, a University of Hawaii history professor and MidWeek columnist, interviewed Akaka, and Richard Borreca, Star-Bulletin political writer, interviewed Case.
"I have done something here that is against the political culture of Hawaii. Maybe that is not the right way for us to continue to do things," said Case, who has four years' experience in Congress.
The 53-year old Democrat, along with his 81-year old opponent, taped separate interviews for PBS Hawaii that will be broadcast tomorrow evening.
During his interview, Case said his campaign "is not just about the transition in the U.S. Senate. This is not just about an orderly transition, or me saying I can do this job. It is about changing a political culture that voters don't like."
"I don't particularly think that the political culture in Hawaii has produced in and of itself the next generation. It has tended to stifle it and hold them back because we have been micro-managers and control freaks," Case complained.
In contrast, Akaka had no complaints about the local Democratic party, which has already had many of its most powerful members, including U.S. Sen. Dan Inouye, endorse him.
"I feel the traditional people of Hawaii will be backing me. When I say traditional I also mean the people who have been in politics before and who have been very concerned about Hawaii's future," Akaka said.
Akaka said he has much more to contribute to Hawaii and that is why he is running for re-election.
"I have the experience, I have the seniority, I have the relationships and I have the influence to move things in the Senate. That makes a huge difference," Akaka said.
Case, however, sees himself as someone who can represent the state for several decades.
Asked why he didn't run for governor this year instead of the Senate, Case said it was all about how long he could serve.
"If I have my way I will go on for a couple of decades in elective public office. You compare four or eight years in the governorship versus a clear position happening now in Congress.
"Both senators are, realistically, nearing some end to their careers. Rep. Abercrombie is in his late 60s. I am 53.
"It is obvious to me that I am responsible for that next generation of leadership. It is a no-brainer as how I should serve Hawaii," Case said.
Both men were asked if they would appear together in a debate and Case said yes, while Akaka would not commit.
"I think voters are entitled to compare us," Case said.
Akaka said he felt his responsibility in the campaign was to let his voters know about him and that could be handled in several ways.
"We will see how things go down the line and when the time comes we will consider that," Akaka said about a possible debate. "I feel my responsibility in the campaign is to inform my constituents about how I am doing, what I want to do and what I can do.
"If I can do it by myself, I feel that is sufficient," Akaka said.
Case called Akaka a liberal and reliable vote for the Democratic minority in the Senate. In contrast, Case says he is a moderate and isn't afraid to vote against Democrats.
"I think Sen. Akaka has tended to be more to the extremes of the party philosophy," Case said during the television interview. "He has definitely followed the party line kind of vote.
"I have demonstrated a much more moderate, middle-of-the-road, independent voting pattern than did Sen. Akaka.
"Clearly, if I don't think my party is going in the right direction, I won't provide support," Case said.
Akaka answered, saying "being a liberal is in the eyes of the beholder."
"I am not liberal when it comes to the armed services. I am not liberal when it comes to the Akaka Bill (native Hawaii sovereignty and recognition legislation)," Akaka said.
ON HAWAIIAN RECOGNITION AND ARCTIC OIL
Here are the opinions of U.S. Sen. Dan Akaka and his challenger U.S. Rep. Ed Case on two major issues that have come before Congress:
Native Hawaiian Sovereignty and Recognition (Akaka Bill):
» Case: "I would be a partner with Sen. (Dan) Inouye, who really has the relationships, seniority and experience to drive federal recognition and has been driving it.
"It would still be called the 'Akaka Bill' and I think it should be called the 'Akaka Bill,' but the fact that the senator is replaced with another senator is not going to make a difference."
» Akaka: "I see my age and experience as being very important to Hawaii. I look forward to continue to press for some of the causes we have. I will be pressing the majority leader (Sen. Bill Frist, R-Tenn.) to set a date for the bill. When this bill is done, it is not the end ... there will still be a need for more federal legislation to take care of the concerns of Hawaiians."
Permit oil drilling in Arctic National Wildlife Refuge:
» Case: "We shouldn't drill in a wildlife refuge. We set it aside because it was incredibly vital not just to Alaska or our country, but to the world. You have to protect the few remaining special places in the world."
» Akaka: "I am an environmentalist, but this is an issue I differ with them, because my vote is for the indigenous people of Alaska. They asked me to help them. They said one way they could get resources and improvements to their quality of life was to drill for oil. The moment they come to me and say they don't want it, I am out."
E-mail to City Desk
THIS EDITION
» Case v. Akaka making waves
» Fuss over kitesurfing could soon blow over
» Small Learning Communities: Class division
» Honoring Onizuka
» Labors of Hercules draw to a close
» Debate back to fixing schools
» Former police officer cleared of assault
» Identity of frozen airman due this week
» Police say 'ice' habit drove lavish purchases
» Boulder crushes hiker on Maui
» For Your Benefit
» Tradition & Evolution
» Portrait show locked in beholders' eyes
» Preserving a tradition of 'lush beauty'
» Isle Pages
» X Marks: Liliuokalani monuments
» Roberts runs unopposed at Turtle Bay
» Wolf Pack get back
» Wolf Pack rattle Rainbow Wahine
» Hickman tames monster waves
» Rodrigues climbs hill
» Seasiders smack Vulcans
» Dulan picks BYU; Te'o off to UNLV
» Kailua takes OIA
» Buffs' comeback beats Spartans
» Mules advance to OIA soccer semis
» Notebook: Turtle Bay Championship
» The Party Zone
» Inside Hawaii, Inc.: Naalei Keaunui
» Stadium authority shirks duty to control booze
» Education Matters
» Labor Issues
Health Options
Joannie Dobbs & Alan Titchnal
Water Ways
Ray Pendleton
Digital Slob
Curt Brandao