Data processing: software development – installation – and managem – Software program development tool – Code generation
Reexamination Certificate
2000-06-26
2003-10-21
Dam, Tuan Q. (Department: 2124)
Data processing: software development, installation, and managem
Software program development tool
Code generation
C345S215000, C345S960000, C709S241000
Reexamination Certificate
active
06637022
ABSTRACT:
TECHNICAL FIELD OF THE INVENTION
This invention relates in general to graphical development environments and more particularly to a graphical development environment for developing the program flow of a program which defines the interactions between a user and a computer to exchange information.
BACKGROUND OF THE INVENTION
Prior art development environments used scripting languages to control the flow of an application. The languages contained individual code constructs called subroutines. Usually, a caller would call a subroutine to perform a certain task, and then receive a return code from the subroutine indicating its result. The caller would then execute a conditional branch instruction conditioned on the return code.
Accordingly, a developer who used subroutines needed to be familiar with all possible return codes that were output by the subroutines. Moreover, the developer needed to design a lengthy branch statement that accounted for all possible returns. Thus, the developer needed to be intimately familiar with the parameters and possible results of the subroutines.
In order to reduce the burden on the developer, prior art development environments had reusable subroutines that performed certain frequently-needed tasks. However, to increase reuse, these subroutines needed to allow for the different conditions that occurred in different calling situations. Therefore, the reusable subroutines had to be parameterized. That is, parameters had to be passed to the subroutine to tell it how to react to different situations. As reusable subroutines grew in complexity, more and more parameters became required. Since the developer had to be familiar with each possible parameter, even reusable subroutines created a heavy burden. In addition, if the application program interface (API) of a reusable subroutine changed, the developer had the burden of locating and changing all of the existing calls to that subroutine.
More recent prior art development environments were graphical in nature. Such graphical development environments used icons to represent various language components. Developers would draw lines or arrows connecting these icons. These lines defined a program flow (call flow). In the prior art, the burden of icon line connection was placed on the developer. Thus, the mechanics of line drawings as well as familiarity with each icon's functionality were burdens to developing successful program flow. For example, icons that behaved as a loop would have different line behaviors than icons that behaved as a branch.
Furthermore, prior art graphical development environments represented a subroutine as an icon in a call flow having a single input line and a single output line, even if the subroutine had multiple return codes. Therefore, the developer still had to be familiar with each possible return code and had to provide a mechanism for dealing with each one.
Prior art non-graphical development environments provided a way to create complex user-defined subroutines without too many parameters: overwritable subroutines. A subroutine can be thought of as containing its various functionalities. Some of these functionalities are always present, others are modified by parameters, and still others can be overwritten by the caller. Prior art non-graphical development environments allowed these overwritable functionalities to be represented as additional subroutines with default functionality defined and invoked by the containing subroutines. The caller of the containing subroutines could replace the default functionality of an overwritable subroutine by providing a corresponding overwriting subroutine. Obviously, the overwritable and overwriting subroutines each shared the same parameters and return codes.
However, the usefulness of overwritable subroutines in prior art was hampered by several limitations. In particular: (1) a lack of graphical representation of overwritable and overwriting subroutines; (2) an overwriting subroutine could only use data that was passed through the pre-defined parameter list—an extreme barrier to extending the default behavior; and (3) overwriting subroutines could only be defined once, not once for each call to the containing subroutine.
Accordingly, there is a need in the art for a graphical development environment that automatically connects icons in accordance with the call flow functionality of the underlying language component.
There is also a need in the art for a graphical development environment that graphically displays subroutines having multiple returns in a manner that eases the burden on the developer.
There is also a need in the art for a graphical development environment which tracks changes in subroutine APIs, so that those changes can automatically be reflected in all calls already made to that subroutine.
There is a further need in the art for a graphical development environment that graphically represents overwritable subroutines and improves their usefulness by enhancing their capabilities.
SUMMARY OF THE INVENTION
The above and other needs are met by a graphical development environment that graphically represents a program flow as a sequence of icons connected by arrows. The icons represent language components such as a while-loop, an if-branch, or a user-defined subroutine. The arrows represent the program flow between the icons. For example, each conditional branch is represented by an icon with several separate arrows branching out, and then returning back to a single program flow. Loop statements are represented by an arrow looping from an icon back to that icon.
A program flow has fixed beginning and end points, initially separated by a single arrow. A developer adds functionality to the program flow by adding icons on existing arrows. The graphical development environment automatically adjusts the program flow to include the new icon and its associated arrows.
For example, if the developer drops an icon representing a loop somewhere between the start and end of the program flow, the environment automatically inserts the icon into the flow at that point and draws an arrow representing the loop. Subsequently, the developer can add other language components within the loop merely by dropping those icons on the arrow representing the loop.
In addition, the graphical development environment displays user-defined subroutine call icons in various ways depending upon functionality. So, if the developer drops an icon calling a user-defined subroutine having multiple returns into the program flow, the development environment automatically draws the arrows representing each possible return from the subroutine. Each return has an associated fixed text label that was defined by the subroutine creator. Similarly, if the developer drops an icon calling a user-defined subroutine having no returns into the program flow, the development environment will show no returns from the subroutine. In this way, the graphical environment will indicate that the call flow stops inside the user-defined subroutine.
In addition, the graphical development environment automatically tracks changes to the APIs of all user-defined subroutines. A subroutine API consists of the parameters, returns, and comments used to interface with that subroutine. A change to any aspect of the API will automatically apply a defunct state to all icons referencing that subroutine. These defunct subroutine call icons are graphically represented by the environment to facilitate location and investigation of the potential ramifications of the API change. The subroutine call icon can be cleared of the defunct state to cause an automatic redraw of the icon and its returns.
In addition, the graphical development environment provides a graphical representation of overwritable subroutines. Additionally, overwritable subroutines are improved by enhancing the ability to modify default functionality. This improvement is accomplished by defining overwriting subroutines in the caller's environment so that even variables not passed through the parameter list can be referenced. The g
Hambleton Myra
Weeren Eric
Dam Tuan Q.
Fulbright & Jaworski L.L.P.
Intervoice Limited Partnership
LandOfFree
Enhanced graphical development environment for controlling... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Enhanced graphical development environment for controlling..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Enhanced graphical development environment for controlling... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3131470