HK1180402B - User augmented reverse engineering - Google Patents

Description

User augmented reverse engineering

Technical Field

The following generally relates to the field of codebase, binary, and database reverse engineering and visual representations of codebases, binaries, and databases.

Background

Typically, an image has thousands of digits. This is especially true for people who attempt to work on pre-existing codebases or otherwise create visual representations of codebase binaries or reverse engineering databases. As computer hardware and software functionality has advanced, code libraries have become larger and more complex. Typically, many different programmers will utilize a single code library or project. These people may not be familiar with all elements of the code base and therefore may need an overall "map" of the code base, or they may need information about a particular structure within the code base. To assist those who have this problem, programs have been developed that provide graphical representations of codebases in the form of flowcharts, running charts, timing diagrams, trees, and the like.

These programs that provide a graphical representation of the codebase can be generally divided into two groups: a static analysis charting program and a run-time analysis charting program. Static analysis programs are more common, but they are limited in many ways. A code base that undergoes static analysis may have many "boundaries" that the static analysis cannot resolve. Furthermore, static analysis cannot determine the actual functionality of the codebase, and they may not be able to locate errors and the like. Furthermore, static codebooks may not focus on the overview of codebooks and specific classes, functions, calls, algorithms, elements, values, parameters, sequences, components, activities, and the like.

Similarly, runtime representations have a series of problems. If the system has an error or fault such that the run cannot complete, the run-time indication may fail. Moreover, the run may only follow a particular course of action, and may not provide a full representation. Other questions may be associated with either or both of the static and dynamic representations.

Therefore, there is a need for systems and methods that overcome the problems in static and runtime codebase graphs.

Disclosure of Invention

In an embodiment, to overcome limitations associated with static and runtime graphical representations of codebases, database schemas, binary databases, and the like, a user may be provided with an option to "focus" the generation of graphical representations during processing of the codebases, database schemas, binary databases, and the like. For example, during graphical generation of a large codebase, a user may select one or more classes, terms, algorithms, values, terms, protocols, sequences, components, activities, use cases, processes, and the like to limit the scope of graphical representation generation. For example, during generation of the graphical representation of the codebase, the user may pause the graphical generation, provide input that removes or selects one or more elements of the graphical generation, which may limit the remainder of the generation to only those sub-elements that are related to the desired element.

In another embodiment, the graph generation may encounter one or more predetermined boundary conditions. Upon encountering a boundary condition, the generation of the graphical representation may determine that it cannot complete the graphical generation within a predetermined set of requirements without additional instructions. Thus, generation may continue without completing the boundary condition until the generation has created a representation of each element it can create, or the generation may pause when the boundary condition is encountered and request user input before continuing the remainder of the generation.

The boundary conditions may be defined in various ways. In one embodiment, the lack of memory may be a boundary condition. In another embodiment, the determination that the generation will take a certain amount of time is a boundary condition. In yet another embodiment, a determination that one or more portions of code require input from an external database or source may be a boundary condition. In another embodiment, when there are multiple portions of a codebase, database schema, binary database, etc. that can provide solutions to functions, processes, calls, etc., the system may prompt the user for possible solutions and the user may then select the desired solution. Further, the user may provide instructions to reverse engineering that cause the generation to treat certain restrictions as boundary conditions. In other words, the boundary conditions may also be user-defined. Those skilled in the art will appreciate that the above is not an exhaustive list of boundary conditions, but merely provides a few examples to generally describe user augmented reverse engineering.

In another embodiment, user augmented reverse engineering may include the possibility of receiving input from a user in real-time during generation of the graphical representation and may also include the ability to detect one or more predetermined boundary conditions and provide the user with an interface for entering information related to the boundary conditions. Thus, during generation of the graphical representation, the user may provide input to the system to complete a previously impossible generation, and the user may also direct the graphical generation during the generation itself, thus focusing on the user-related portions of the codebase, database schema, binary database, and the like.

In another embodiment, any of the above embodiments may be provided during static generation of a code library or the like and/or during runtime generation of a code library or the like. During any type of generation, it is contemplated that a user interface for information input may be provided to allow a user to focus on a codebase, database schema, binary database, or the like or to allow a user to satisfy a request for a solution to a predetermined boundary condition.

Drawings

FIG. 1 depicts an example computer system in which the disclosed subject matter may be implemented.

FIG. 2 depicts a flow diagram of the operation of aspects of user augmented reverse engineering.

FIG. 3 depicts a flow diagram of the operation of aspects of boundary conditions in user augmented reverse engineering.

FIG. 4 depicts a sample graphical representation of a codebase, database schema, binary database, etc., wherein the codebase, database schema, binary database, etc., have boundary conditions.

Fig. 5(a) - (b) depict sample graphical representations of codebases, database schemas, binary databases, etc., where a portion of the codebases, database schemas, binary databases, etc., have been excluded from graphical generation.

FIG. 6 depicts a flow diagram of an example method of overcoming boundary conditions in a codebase, database schema, binary database, or the like.

FIG. 7 depicts a flow diagram of one embodiment of a method for utilizing an active environment to direct the generation of a graphical representation of a codebase, database schema, binary database, or the like.

FIG. 8 depicts a flowchart of one embodiment of a computer-readable medium having instructions for user augmented reverse engineering.

Detailed Description

Although "codebase" is generally referred to in the following description without including all other options, it should be understood that embodiments disclosed herein include any other type of codebase, instructions implemented on a computer-readable medium, database schema, binary schema, database, code, and the like.

In one embodiment, user augmented reverse engineering includes a computer-implemented interactive method for creating graphical representations of codebases, database schemas, binary databases, and the like. The method includes generating a graphical representation of a first portion of a codebase, database schema, binary database, or the like; determining that a predetermined boundary condition exists; prompting a user for input relating to a boundary condition; receiving user input regarding a boundary condition; and generating a graphical representation of a second portion of the codebase, database schema, binary database, or the like.

In another embodiment, user augmented reverse engineering includes a computer-implemented interactive method for creating a graphical representation of a codebase. The method includes reviewing a first portion of a codebase; generating a graphical representation of a first portion of a codebase; displaying a graphical representation of a first portion of a codebase on a display; receiving an input during generation of a first portion of the graphical representation, wherein the input comprises an interruption of the generation of the graphical representation; and resuming generation of the graphical representation, wherein the resumed generation excludes the second portion of the codebase from the graphical representation.

In another embodiment, user augmented reverse engineering includes a computer readable storage medium having instructions stored thereon for execution on a processor. The instructions include instructions for: reviewing a first portion of a codebase; generating a graphical representation of a first portion of a codebase; receiving an input, wherein the input changes a scope of the graphical representation; reviewing a second portion of the codebase; generating a graphical representation of a second portion of the codebase; and displaying a graphical representation of the codebase.

Embodiments for enhanced reverse engineering may be performed on one or more computer systems. FIG. 1 and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the disclosed subject matter may be implemented.

The term circuitry used throughout this specification may include hardware components such as hardware interrupt controllers, hard drives, network adapters, graphics processors, hardware-based video/audio codecs, and the firmware used to operate such hardware. The term "circuitry" may also include a microprocessor, an application specific integrated circuit, and/or one or more logical processors, such as one or more cores of a multi-core general processing unit configured by firmware and/or software. A logical processor may be configured by instructions that embody logic that may be used to perform functions loaded from a memory, such as RAM, ROM, firmware, and/or mass storage. In an example embodiment where circuitry includes a combination of hardware and software, an implementer may write source code embodying logic that is subsequently compiled into machine readable code that can be executed by a logical processor. Because those skilled in the art will appreciate that the prior art has evolved to the point where there is little difference between hardware implemented functions or software implemented functions, the selection of hardware versus software to implement the functions described herein is merely a design choice. In other words, the choice of hardware implementation or software implementation is left to the implementer as it will be appreciated by those skilled in the art that software processes can be transformed into equivalent hardware structures, and that hardware structures can themselves be transformed into equivalent software processes.

Referring now to FIG. 1, an exemplary computing system 100 is depicted. Computer system 100 may include a logical processor 102, e.g., an execution core. Although one logical processor 102 is shown, in other embodiments, the computer system 100 may have multiple logical processors, e.g., multiple execution cores per processor substrate, and/or multiple processor substrates that may each have multiple execution cores. As shown in FIG. 1, the various computer-readable storage media 110 may be interconnected by one or more system buses that couple the various system components to the logical processor 102. The system bus may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. In an example embodiment, computer-readable storage media 110 may include, for example, Random Access Memory (RAM) 104, storage 106 (e.g., an electromechanical hard drive, a solid state hard drive, etc.), firmware 108 (e.g., flash RAM or ROM), and removable storage 118 (e.g., a CD-ROM, a floppy disk, a DVD, a flash drive, an external storage device, etc.). It should be appreciated by those skilled in the art that other types of computer-readable storage media can be used, such as magnetic cassettes, flash memory cards, and/or digital video disks.

Computer-readable storage media 110 may provide non-volatile and volatile storage of processor-executable instructions 122, data structures, program modules, and other data for computer 100. A basic input/output system (BIOS) 120, containing the basic routines that help to transfer information between elements within computer system 100, such as during start-up, may be stored in firmware 108. A number of programs may be stored on firmware 108, storage device 106, RAM104, and/or removable storage device 118, and executed by logical processor 102, including an operating system and/or application programs.

Commands and information may be received by computer 100 through input devices 116 that may include, but are not limited to, a keyboard and pointing device. Other input devices may include a microphone, joystick, game pad, scanner, or the like. These and other input devices are often connected to the logical processor 102 through a serial port interface that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port, or Universal Serial Bus (USB). A display or other type of display device is also connected to the system bus via an interface, such as a video adapter, which may be part of the graphics processing unit 112 or may be connected to the graphics processing unit 112. In addition to the display, computers typically include other peripheral output devices (not shown), such as speakers and printers. The exemplary system of FIG. 1 can also include a host adapter, Small Computer System Interface (SCSI) bus, and an external storage device connected to the SCSI bus.

The computer system 100 may operate in a networked environment using logical connections to one or more remote computers. The remote computer may be another computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer system 100.

When used in a LAN or WAN networking environment, computer system 100 may be connected to the LAN or WAN through a Network Interface Card (NIC) 114. The NIC114 (which may be internal or external) may be connected to the system bus. In a networked environment, program modules depicted relative to the computer system 100, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections described are exemplary and other means of establishing a communications link between the computers may be used. Further, while it is envisioned that numerous embodiments of the disclosed subject matter are achievable with particularly well-suited computerized systems, nothing in this document is intended to limit the disclosed subject matter to such embodiments.

FIG. 2 depicts one possibility of a logic flow diagram 200 depicting the implementation of user augmented reverse engineering. Fig. 2 depicts initiating graphical generation at 202 based on input 201. The graphical generation initiated at 202 includes any visual representation of a code base known in the art. Thus, in one embodiment, the graph generation may be, for example, a flow chart, a run chart, a timing diagram, a tree or graph, a graph, an image, or any other manner of representing a codebase or functionality of a codebase.

The structure of the graphical generation initiated at 202 may also be any structure known in the art. The graph generation may, for example, track one or more particular aspects of the codebase. The graphical representation may be any of the aforementioned graphical representations that may plot a particular process, value, element, class, sequence, component, time frame, activity, use case, parameter, functionality, sub-process, element, input, output, item, algorithm, etc., and that may represent a time sequence of inputs, outputs, processes, sequences, elements, values, parameters, functionality, sub-processes, items, etc., and may further be constructed based on memory, internal relationships, external relationships, or in any other manner known in the art.

In an embodiment, one or more inputs 201 may be provided to guide one or more aspects of a user-implemented reverse engineering procedure prior to initiating the graphical generation at 202. For example, one or more inputs may be used to focus the generation of the graphical representation on a particular element prior to initiating the generation. Input 201 may be any value that may narrow, direct, focus, or otherwise alter the generation of the graphical representation. As another example, the input 201 to the user augmented reverse engineering may be a selection of the type of graphical representation desired by the user, such as a timing diagram or a flow chart. Further, the input 201 may define the structure of the graphical generation.

In one embodiment, a user may provide one or more inputs 201 to establish the boundary conditions for graphical generation. For example, the one or more boundary conditions may be predetermined. In such an embodiment, input to the graphical generation may result in user augmented reverse engineering to add boundary conditions. As another example, the input 201 may be utilized to change the boundary conditions previously set. As one non-limiting specific example, the user may select the amount of time allotted for the graphical generation before the system will determine that it has reached the boundary condition. In this example, the user may specify a time limit of 5 minutes, where when it is determined that the graphical generation will take more than the time allotted in the boundary condition, the user augmented reverse engineering provides the user with an interface that allows them to guide the generation of the graphical representation in one or more ways.

In one embodiment, the graphical generation is initiated at 202, regardless of the structure of the graphical generation, the type of graphical representation, the preselected boundary conditions, and any other initial inputs 201. After initiation 202, the graphical generation may include a user interface 204.

The user interface 204 allows for the entry of information for graphical generation. The user may enter input for the graphical generation during generation and/or after generation is complete. The user interface 204 may be implemented by any means of receiving input from a user, program, or system known in the art. For example, the user interface may allow information to be entered via one or more of a mouse click, a keyboard, a joystick, by voice activation, a touch pad or screen, a wired or wireless connection, or any other means known to those skilled in the art.

During generation of the graphical representation, the generated completed portion may be displayed on the display 205. For example, each time the user augmented reverse engineering program determines, for example, the next step in the flowchart, that step may be displayed on an output device, 205. The output device may be any device known in the art for displaying visual information to a user. In one embodiment, the output is displayed on a screen or projected so that the graphical generation can be seen.

The displayed graphically-generated portion (205) may be associated with a user interface (204). For example, in one embodiment, for each element displayed in the graphical representation, an input may be associated with the element. For example, if a flowchart has been constructed and 5 steps in the flowchart have been displayed, the user may move a mouse and click on any of the five steps, thereby providing input associated with the selected graphical element of the flowchart. The selection of the particular element may provide all input from the user regarding the particular element, or it may be used to limit the possible input by the user.

As another non-limiting example of a user interface 204, a single user interface 204 may be provided regardless of the number of elements displayed on the graphical representation. For example, there may be an option for the user to pause the graphical generation at any time. After the pause, additional user input may be provided to direct, focus, or otherwise provide input to the graphical generation.

Thus, when the user augmented reverse engineering 200 is run, it is configured to receive any of the above inputs at 206. If no input is received at 206, the generation process may continue. However, if an input is received at 206, the input may have a graphical generated interrupt 208 associated therewith. As another example, the input may be configured to interrupt graphics generation 208. The interruption 208 of the graphical generation may be an interruption that causes the system to pause reviewing the codebase and may also cause it to stop adding graphical elements to the graphical display. Although the graphical generation may be interrupted at 208, user augmented reverse engineering may preserve information associated with the graphical generation prior to the point of interruption.

After the interruption 208 of the graphical generation, the user augmented reverse engineering may request additional input from the user, or the input 204 provided from the user interface may be sufficient to initiate the resumed graphical generation 210. For example, the input received at 206 may include only the interrupt 208. In this example, the user may be prompted to provide additional input to guide the generation.

However, in another embodiment, the interrupt input may also be configured to direct the generation of the graphical representation that is restored at 210. For example, if the user selects a single element of the flowchart by clicking on it, the system may interrupt the initial generation of the graphical representation and then resume the graphical generation, with the resumed generation focusing on the clicked-on aspect of the flowchart.

Thus, after receiving user input sufficient to resume graphic generation, the user may be provided with an option to resume graphic generation at 210, or, as another example, graphic generation may be automatically resumed at 210. In either case, the generation may be restorable, and the user interface described above will again be provided to the user if the user desires to include additional input.

At any time during the graphical representation generation, the user augmented reverse engineering may encounter a predetermined boundary condition at 212. In one embodiment, the predetermined boundary condition may be any situation where the generation cannot complete the graphical representation. For example, if a codebase undergoing graph generation requires external input that is not available to the codebase, the graph generation may determine that there is a boundary condition 212. As another example, if within the codebase there are several possible solutions to calls, problems, algorithms, etc., the system may determine that there is a boundary condition 212. Any other limitations that prevent the graphical representation from being completed will be known to those skilled in the art and are included herein.

In additional embodiments, the boundary conditions may be predetermined based on other factors, such as the time taken to provide the graphical representation or the amount of memory or space on the display. For example, if the amount of time to complete a portion (including but not limited to all) of the generation exceeds a predetermined amount, user augmented reverse engineering may determine that there is a boundary condition 212.

After determining that there is a boundary condition 212, the user may be prompted for a solution 214. As one example, the interface may open, pop up, become active, etc., which requires the user to enter information before a resume is generated.

As one example of a prompt solution 214, graphical generation may run, and the user augmented reverse engineering 200 may determine that there are a limited number of available solutions to calls, elements, processes, algorithms, etc. in the codebase. As a first example, a user may be provided with a number of possible solutions and asked to select which is the appropriate solution. In this example, the user's input is limited to only those solutions that are "meaningful" within the context of the codebase.

In another embodiment of the prompt solution 214, input from the user may be limited in one or more ways. For example, the type of input may be limited to only numerical solutions or solutions having strings, functions, processes, elements, values, etc. associated therewith. In general, prompts to a user may be limited in any manner that may reduce the likelihood of inappropriate input from the user.

In an additional embodiment of the hint solution 214, no restrictions are placed on possible inputs. In this example, the user may provide any response that may be available to them.

After prompting for a solution at 214 and input by the user, input is received at 216. If possible, the generation of the graphical representation will continue 216. By way of example, if the solution at 214 is sufficient to continue generating 216, the generation will continue before the user interface is provided, and the generation will continue until user input is received or another boundary condition is encountered at 212, or if no additional user input or boundary condition is encountered, the generation will be complete at 218. The solution received at 216 may influence the generation advance in any manner known in the art.

It should be noted that FIG. 2 depicts one example of user augmented reverse engineering. In another embodiment, the user interface at 204 may not be provided and generation will continue unless a boundary condition is encountered. In another embodiment, the generation will not pause at a predetermined boundary condition and will only include a user interface 204 that can interrupt and affect the generation. Other additions, or deletions, or reordering of the elements depicted in fig. 2 are considered within the scope of reverse engineering for enhancement, and other arrangements of the elements of fig. 2 may be understood by those skilled in the art.

FIG. 3 depicts another embodiment of user enhanced reverse engineering with different logic than that described above with reference to FIG. 2. For example, in one embodiment, graphical generation may be initiated at 254 using input 252. As noted above, inputs 252 may limit the scope of generation, etc., they may determine the type of graphical output and they may define the boundary conditions of the system. Any other input for user augmented reverse engineering may be included in input 252.

After receiving input 252 and initiating graphical generation at 254, the system may then perform graphical generation 256. During the generation of the graph at 256, one or two or ten or any other number of boundary conditions may be reached. In one embodiment, the graphics generation may not pause each time a boundary condition is determined. Rather, the graphical generation may be paused only after the generation has satisfied the requirements of the input or otherwise performed as much of the graphical generation as possible on the first portion of code. In one embodiment, performing as much generation as possible without having the user input respond to the boundary condition may reduce the likelihood of the user inputting inappropriate information.

After the graphical generation 256, user augmented reverse engineering may provide a graphical representation showing the generation and one or more instances of boundary conditions 258 in the codebase. In one embodiment, each boundary condition 258 may be identified on the display by any means known in the art. After the boundary condition 258 is identified, the user may be prompted to check the boundary condition 260. In one embodiment, each interface may provide access to each boundary condition and allow input by a user. Input by the user may be limited in any of the ways described above with reference to fig. 2. The user may select to satisfy each boundary condition of the graphical generation highlighting or they may optionally provide a solution to the boundary condition. Thus, the user may optionally provide input for any number of boundary conditions.

When the user enters a solution to the boundary condition in response to the prompt at 260, the user augmented reverse engineering may receive the solution at 262. After receiving all solutions, or based on input from the user, user augmented reverse engineering may perform graphical generation of a codebase on portions of the solutions having boundary conditions. In the generation 262, new boundary conditions may be discovered. At 260, the user may again be prompted to satisfy those boundary conditions. In other words, the process may continue until there are no more boundary conditions or until the user has provided input for all of the boundary conditions he wishes, at which time the graphics generation 264 will be completed.

FIG. 4 depicts an example of a boundary condition where the system cannot determine the solution of a call in a codebase. In FIG. 4, graphical generation 300 of a process occurs, and the flow diagram of FIG. 4 may be a graphical representation 300 of a process, such as a code library. A starting point 302 is generated at which a process can be determined. From start point 302, the generation may next determine that process 300 has been associated with process A, 304. Process a may output a value of 1 at 306 and a value of 2 at 312 based on a yes or no solution to process a at 304. The value 1 at 306 and the value 2 at 312 may be utilized by algorithm B at 308 and algorithm a at 316. At this point, however, the generation may determine that it requires a value from external database 1, 310. If information from external database 1 is not available for generation at 310, the generation may determine that it cannot complete graphical representation 300. In this case, the user augmented reverse engineering may prompt the user for input at 320 in order to complete the graphical generation.

FIG. 4 depicts an embodiment in which the graphical generation cannot be accomplished because the information contained in external database 1 is not available for user augmented reverse engineering at 310. As noted above, this is only one boundary condition, and the figure is not intended to limit the various types of boundary conditions that may occur. As described above, a user, programmer, or the like may select an arbitrary condition and predetermine that the selected condition has a boundary condition associated therewith. Further, those skilled in the art will appreciate that user augmented reverse engineering may be configured to incorporate any condition, such as time, memory, a missing element, a set of possible elements, etc., as a predetermined boundary condition.

Fig. 5(a) -5 (b) depict example embodiments of results generated based on input focus patterns from a user. 5(a) - (b) show a display of graph generation in progress, where the graph generation includes a start point 402. As noted above with reference to FIG. 2, when graphics generation begins 202, an interface for input may be provided. Although not depicted in fig. 5(a) - (b), it should be understood that an interface for input is provided to the user when creating the diagrams in fig. 5(a) - (b). At 404, a first layer of the codebase may be reviewed and the display may include a graphical generation illustrating several processes. In the example of FIG. 5(a), processes A-YY are depicted. In FIG. 5(a), after the graphical generation of layer 1 at 404, the user augmented reverse engineering may next go to layer 2, 406, and begin the graphical generation of that layer. Layer 2 may comprise any element of a codebase and may be represented in any manner known in the art. However, referring to FIG. 5(a), based on the number of initial processes, and assuming that there are at least two or three elements in layer 2 at each process 406 in layer 1 at 404, the graphical display has become large and cumbersome.

FIG. 5(b) depicts the graphical representation after the user has provided input. In FIG. 5(B), at 408, the user selects process B for layer 1. Thus, the remainder of layer 1 at 404 and layer 2 at 406 is excluded for generating the remainder. Indeed, as depicted in fig. 5(B), selecting process B at 408 may exclude all layer 3 or other functions related to process a or any of processes C through YY. Thus, by providing an interface to a user to interrupt the graphical generation and provide input and exclude a portion of the codebase based on the input, the complexity, time, and confusion of graphical generation may be greatly reduced.

FIG. 6 depicts a flow of an example embodiment for responding to a boundary condition during user augmented reverse engineering. At step 502, user augmented reverse engineering may generate a graphical representation of a first portion of a codebase. Generating the first portion 502 of the codebase may include receiving user input to set the type of graphical representation and setting up or implementing a user interface to set or change boundary conditions to focus the generation, etc. The generating may also include reviewing the code, wherein the reviewing is a static analysis or a runtime analysis, and creating a graphical representation of the code that may be displayed on a display.

At step 504, user augmented reverse engineering may determine a predetermined boundary condition. The boundary conditions may be defined by a user or programmer, or they may occur within the code itself. In one embodiment, the boundary condition relates to memory or time. In another embodiment, the boundary condition relates to a number of possible solutions within the code itself, and/or the boundary condition may relate to the inability to obtain information from an external source, such as a database, program, or the like. Other boundary conditions are possible and those skilled in the art will appreciate that the above is not limiting and only provides a few examples of boundary conditions.

Step 504 invokes a boundary condition. It should be understood that in one embodiment, multiple boundary conditions are found to exist. User augmented reverse engineering may complete any portion of the generation of the graphical representation before the boundary condition is resolved. Thus, in one embodiment, if the all-static generation occurs before prompting the user to provide a solution to the boundary condition, the user input is less likely to be erroneous.

At step 506, the user may be prompted to provide input regarding the boundary condition found to exist at 504. The prompt to the user may be on a graphical display. The prompt may have a limited number of options from which the user may select, or it may be an open request for input. The prompt may also be limited to one type of input, such as a number, letter, string, or any other type of input of a particular length. Those skilled in the art will appreciate that the above is not limited to what the prompt is or what the user may be prompted to do, but rather merely provides a series of examples related to the prompt.

At 508, input from a user may be received. User input may be provided in any manner known in the art, for example, via a keyboard or mouse, touchpad or touch screen, voice activation, wired or wireless connection, or any other manner. The input may be related to a boundary condition and may affect the graphics generation in one or more ways. For example, receiving a solution to the boundary condition may allow user augmented reverse engineering to build a representation of a new portion of the codebase, or it may focus the generation, or it may narrow the scope of the graphical representation.

At 510 of FIG. 6, in one embodiment, graphics generation may resume. In another embodiment, it may be restarted with different parameters, or it may hold a portion of the previous generation and initiate a new generation of another portion of the codebase. The second portion may be regenerated in any manner of minification, undergoing broader generation or focusing. As described above, there may be a single boundary condition that is satisfied, or multiple boundary conditions may be satisfied. Thus, the generated second portion may relate to a solution for a single boundary condition, or it may relate to a solution for multiple boundary conditions.

FIG. 7 depicts a flowchart of an example embodiment of user augmented reverse engineering for a user providing input to affect graphical generation. At step 602, user augmented reverse engineering may generate a graphical representation of a first portion of a codebase. Generating the first portion 602 of the codebase may include receiving user input to set the type of graphical representation, to set or change boundary conditions, to set up or implement a user interface, to focus the generation, and so forth. The generating may also include reviewing the code, wherein the reviewing is a static analysis or a runtime analysis, and creating a graphical representation of the code that may be displayed on a display.

At step 604, user augmented reverse engineering may include displaying a graphical representation 604 of a first portion of a codebase. The display may be any means or manner of displaying information to the user, such as a screen, projection, sound, and the like. The display may be a real-time or substantially real-time display such that when one or more elements of the user augmented reverse engineering determination codebase should be included in the graphical generation, they are displayed. This may provide information to the user via the display in a timely manner at 604.

At step 606 of FIG. 7, an interface may be provided to a user, where the interface is configured to receive input related to graphical generation. The interface can receive input in any manner known in the art. For example, mouse clicks, keyboard input, wired or wireless connections, touch pads or screens, etc. may be configured for use with the interface. The interface may also be associated with a state of graphical generation. For example, when generating add elements, each element may become interactive or may otherwise be included in an interface such that a user may select or otherwise interact with the generated elements. Interface 606 may include inputs to solve, add, or subtract from any element of the graphical generation. The input may affect the graphical generation in any manner known in the art, including focusing the generation, zooming out the generation, or expanding the generated scope.

At step 608, the user augmented reverse engineering may receive an input via the interface during the generation of the first portion of the graphical representation, wherein the input includes an interruption of the generation of the graphical representation. Thus, during the generation of the graphical representation itself, the user may provide input and affect the generation in any manner. The input will interrupt the generation and allow the impact of the generation. The generation may be scaled down, changed, expanded, elements may be excluded or focused, etc. In one embodiment, the input does not change the generation at all. The above serve as a few examples and do not limit the scope of the impact that the input has. The input may also change boundary conditions, etc. Those skilled in the art will recognize other possibilities for the impact of the input on the generation of the graphical representation.

At step 610, the generation of the graphical representation may resume after the interruption. The resumed generation may exclude a portion of the codebase, thus narrowing the scope of the generation. This may be a result of focusing or zooming out.

FIG. 8 depicts a flow diagram of an example embodiment of user augmented reverse engineering. At step 702, a first portion of a codebase is reviewed. The review may include determining the functionality or timing or any other aspect of the elements of the codebase. During review, the graphical representation may be associated with an element of the codebase being reviewed.

At step 704, a graphical representation of a first portion of a codebase may be constructed. Generating the first portion 702 of the codebase may include receiving user input to set the type of graphical representation, to set or change boundary conditions, to set up or implement a user interface, to focus the generation, and so forth. The generating may also include reviewing the code, wherein the reviewing is a static analysis or a runtime analysis, and creating a graphical representation of the code that may be displayed on a display.

At step 706, input to the user augmented reverse engineering may be received, wherein the input changes the scope of the graphical representation. For example, the input may be a mouse click, a keyboard input, a wired or wireless connection, a touch pad or touch screen, or the like, that may be configured to act as an input. The input may include an interrupt and may affect the generated range in a manner known in the art. The generation may be scaled down, changed, expanded, elements may be excluded or focused, etc. In one embodiment, the input does not change the generation at all. The above serve as a few examples and do not limit the scope of the impact that the input has. The input may also change boundary conditions, etc. In one embodiment, the request for input is in response to determining that a boundary condition exists. Thus, the input may be a solution to the boundary condition. Those skilled in the art will recognize other possibilities for the impact of the input on the generation of the graphical representation.

At step 708, a second portion of the codebase may be reviewed. The review may include determining the functionality or timing or any other aspect of the elements of the codebase. During review, the graphical representation may be associated with an element of the codebase being reviewed. The second portion of the codebase may be any portion of the codebase that is affected by the input. It may be a smaller portion, a new portion, the same portion, or any combination thereof. The second part may be the same type of graphical representation or it may differ in one or more ways. The second part may relate to boundary conditions or inputs during the generation itself. The second portion may then undergo generation of a graphical representation at 710. This may include associating the elements and preparing for display at 712, where the display is any display known in the art as described above.

It will be appreciated that the configurations and/or approaches described herein are exemplary in nature, and that these specific embodiments or examples are not to be considered in a limiting sense. The specific routines or methods described herein may represent one or more of any number of processing strategies. As such, various acts illustrated may be performed in the sequence illustrated, in other sequences, in parallel, and so forth. Also, the order of the above-described processes may be changed.

Additionally, the subject matter of the present disclosure includes combinations and subcombinations of the various processes, systems and configurations, and other features, functions, acts, and/or properties disclosed herein, as well as any and all equivalents thereof.

Claims (13)

1. A computer-implemented interactive method for creating a graphical representation of a codebase, comprising:

generating a graphical representation of a first portion of the codebase;

determining that one or more predetermined boundary conditions exist within the first portion of the codebase when generating the graphical representation of the first portion, wherein determining that the one or more predetermined boundary conditions exist comprises: determining that there are insufficient computing resources to generate a graphical representation of the codebase, that external data is required for the codebase, or that a graphical representation of a second portion of the codebase has a plurality of possible solutions;

prompting a user for input relating to the one or more boundary conditions;

receiving user input regarding the one or more boundary conditions; and

generating a graphical representation of a second portion of the codebase that is constrained by one or more boundary conditions, wherein generating includes static analysis or runtime analysis of the second portion of the codebase and creating a graphical representation of the second portion of the codebase that is displayed on a display.

2. The method of claim 1, further comprising prompting a user for a plurality of options for each of the one or more boundary conditions, the plurality of options restricting the input.

3. The method of claim 2, further comprising selecting the plurality of options based on possible solutions to each of the one or more boundary conditions.

4. A computer-implemented interactive method for creating a graphical representation of a codebase, comprising:

generating a graphical representation of a first portion of the codebase;

displaying a graphical representation of a first portion of the codebase;

determining that a predetermined boundary condition exists by at least determining that there are insufficient computing resources to generate a graphical representation of the codebase, that external data is required by the codebase, or that a graphical representation of a second portion of the codebase has a plurality of possible solutions;

providing an interface to a user, the interface configured to receive input related to generation of a graphical representation of a first portion of the codebase;

receiving an input via the interface during generation of the graphical representation of the first portion based at least in part on determining that the boundary condition exists, wherein the input comprises an interruption of the generation of the graphical representation; and

restoring generation of the graphical representation of the codebase to a restored generation, wherein the restored generation excludes the second portion of the codebase from the graphical representation such that the graphical representation of the codebase may be displayed on a display device.

5. The method of claim 4, wherein the input further comprises a selection of a third portion of the codebase.

6. The method of claim 5, wherein the second portion of the codebase excluded from the resumed generation comprises a portion of the codebase that is not included in the third portion of the codebase.

7. The method of claim 5, wherein the restored generation of the graphical representation of the codebase includes a graphical representation of a third portion of the codebase.

8. A computer-implemented method, comprising:

reviewing a first portion of a codebase;

generating a graphical representation of a first portion of the codebase;

determining that a predetermined boundary condition exists by at least determining that there are insufficient computing resources to generate a graphical representation of the codebase, that external data is required by the codebase, or that a graphical representation of a second portion of the codebase has a plurality of possible solutions;

receiving an input based at least in part on the boundary condition encountered in the first portion of the codebase based on a graphical representation of the first portion, wherein the input changes a scope of the graphical representation of the first portion;

reviewing a second portion of the codebase based on receiving the input;

generating a graphical representation of a second portion of the codebase based at least in part on a static analysis or a runtime analysis of the second portion of the codebase; and

displaying a graphical representation of the codebase.

9. The method of claim 8, further comprising:

providing an interface for receiving instructions during generation of the graphical representation of the first portion;

receiving an input via the interface, wherein the instruction comprises an interruption of the generation of the graphical representation of the first portion; and

resuming generation of the graphical representation of the codebase, wherein the resumed generation excludes a third portion of the codebase from the graphical representation.

10. The method of claim 9, further comprising providing an interface for receiving a request during generation of the graphical representation of the restored codebase.

11. The method of claim 8, further comprising determining that a boundary condition exists in the first portion of the codebase.

12. The method of claim 11, further comprising:

providing an interface related to the boundary condition; and

receiving a solution to the boundary condition as a response from the interface.

13. The method of claim 12, wherein determining that a boundary condition exists comprises: it is determined that data from a source external to the codebase is required to complete generation of the graphical representation of the codebase.